It would be really nice to be able to use ebuild functions in hook scripts of webapp-config. Some examples concerning OTRS which im working currently on: - Use enew{user,group} for creating an user for OTRS' cronjobs - Detect usage of unicode useflag to enable UTF-8 when creating the webapp-instance - Have prettier output/error handling in hook scripts ... currently I'm sourcing /etc/init.d/functions.sh for this - .... much more... I think we'll start loving it, as soon as it's available for hook scripts ;-) Currently the hooks are running inside a sandbox, but there aren't any proper "workarounds" for doing operations like provided by all the do* functions in ebuilds etc. Thank you!
(In reply to comment #0) > It would be really nice to be able to use ebuild functions in hook scripts of > webapp-config. Some examples concerning OTRS which im working currently on: > > - Use enew{user,group} for creating an user for OTRS' cronjobs This should usually not happen during the webapp-config run. webapp-config is mainly meant to install the htdocs and should not be really involved in system specific tasks. In case of otrs I assume it might also be sufficient to create the users in the ebuild phase. Or is there a specific reason for disallowing that? > - Detect usage of unicode useflag to enable UTF-8 when creating the > webapp-instance What is the specific action required by webapp-config if the unicode USE-Flag is activated? Is this something that may also be handled in the ebuild phase? After all USE-Flags are specifically meant for emerge and porting the concept to webapp-config will be difficult. > - Have prettier output/error handling in hook scripts ... currently I'm > sourcing /etc/init.d/functions.sh for this I don't see a real problem with sourcing /etc/init.d/functions.sh. On the other hand hook scripts are meant to do really small, minor jobs required when setting up a webapp. They should not be extremely complex because that means that there is a higher chance for failure. > - .... much more... I think we'll start loving it, as soon as it's available > for hook scripts ;-) > > Currently the hooks are running inside a sandbox, but there aren't any proper > "workarounds" for doing operations like provided by all the do* functions in > ebuilds etc. That is intentional. A hook script will never do anything OUTSIDE of this sandbox. If anything system-critical has to be done, it has to be handled by webapp-config. > > Thank you! >
(In reply to comment #1) > This should usually not happen during the webapp-config run. webapp-config is > mainly meant to install the htdocs and should not be really involved in system > specific tasks. I've always dreamed of 'webapps' being a subclass of ebuilds... but realization of my dreams seems to be far far away ;-) > In case of otrs I assume it might also be sufficient to create the users in the > ebuild phase. Or is there a specific reason for disallowing that? This won't work, because every instance of OTRS needs an own user with it's own cronjobs and permissions. Predicting the needed users when running the ebuild is impossible, unless we add the clairvoyant() function to ebuilds ;-) > > - Detect usage of unicode useflag to enable UTF-8 when creating the > > webapp-instance > > What is the specific action required by webapp-config if the unicode USE-Flag > is activated? Is this something that may also be handled in the ebuild phase? > After all USE-Flags are specifically meant for emerge and porting the concept > to webapp-config will be difficult. This could probably be done in the ebuild. It defines the default encoding for database, logfiles, notification mails, HTML output etc. based on the unicode USE-Flag when setting up a new instance. > I don't see a real problem with sourcing /etc/init.d/functions.sh. On the other > hand hook scripts are meant to do really small, minor jobs required when > setting up a webapp. They should not be extremely complex because that means > that there is a higher chance for failure. I know about that, but all this workarounds made the whole process extremely complex. I added a lot of checks to the scripts to prevent eventual failures. > That is intentional. A hook script will never do anything OUTSIDE of this > sandbox. If anything system-critical has to be done, it has to be handled by > webapp-config. Yeah, thats correct. But when there's a function not available due to restrictions of the sandbox, a function for doing this while being watched by the sandbox should be available to for essential operations (compare enewuser/enewgroup in ebuilds). Regards, Elias P.
