Hello, Am Mittwoch, 28. Dezember 2011 schrieb Cristian Rodríguez:
On 28/12/11 16:01, Per Jessen wrote:
Cristian Rodríguez wrote:
Try the following, create a program that is able to figure out what exactly init scripts do,
It already exists and is called /bin/bash -x (I know that this probably isn't the answer you wanted to hear ;-)
if it really is what the packager intended.
Now it becomes really interesting. You have a device to read /dev/brain? Please tell me where I can buy it! ;-) OK, enough fun for one mail ;-) I agree with you that service files are much easier to parse than initscripts. Nonetheless that's only useful if the ExecStart points to the daemon directly - the argument becomes pointless if ExecStarts runs a wrapper script.
Also try auditing all uses of /tmp , sed , awk, etc ensuring people are using them correctly.
Auditing (temp)file usage is easy. That's something aa-genprof (and in general, AppArmor in learning mode) can do easily.
Well, people is asking for fairly ridiculous things.
Oh yeah. Like output from init scripts. Yup.
Im not talking about incompatibilities or bugs, I am talking about requests that ask for systemd to manage services that do not provide proper exit status codes.
That method works for starting daemons, and I agree that they should provide proper exit status codes. OTOH, I already explained some days ago that in some cases (like AppArmor) ExecStatus would really make sense because there is no daemon/process you can check. To make things more practical: I'm currently rewriting PostfixAdmin from linear PHP files to using classes, and there are lots of similarities with the initscript vs. systemd discussion. Just to name an example: the new code can generate HTML forms based on an array, so basically adding a new module to PostfixAdmin means to create a new class that defines an array containing the database fields relevant for that module, and you get all the handling (read from database, store in database, input validation etc. automatically). Sounds easy? In theory it is - just validate the form input and store it in the database. Unfortunately, there are lots of exceptions. For example - when creating a mailbox, an alias for it needs to be added, and a mail needs to be sent to create the mailbox on disk - the "password" and "repeat password" fields have to match - checking password strength is good, but users will kill me if I do the same with their remote passwords when setting up fetchmail jobs - in the web form, creating aliases and mailboxes is easier with a split localpart text input and domain dropdown, but the class and the database expect the complete mail address - data read from the database may need post-processing (for example to find out if a mailbox alias is forward-only or store-and-forward) - and much more (and please keep in mind that PostfixAdmin "just" fills some database tables that are then used by postfix) Needless to say that I had to add *lots of hooks* to support all those exceptions - otherwise I would need to rewrite/overwrite the whole "store" function from the parent class just to send out a mail and create an alias when creating a mailbox. Instead, I can write a small "storemore" function where I can do the additional tasks, and let the parent class' store function do the main job. To come back to systemd and AppArmor: Yes, I can of course start a watchdog daemon in ExecStart that (after loading the profiles) runs aa-status every 10 seconds and errors out if something goes wrong. And I really would check every 10 seconds so that everybody running "systemctl status" gets an (at least nearly) up-to- date result. Or I could use the ExecStatus "hook" in the service file, which could then run aa-status when someone runs "systemctl status". Now please tell me which way is smarter ;-) Regards, Christian Boltz -- if this crashes as well, make sure to create a bnc entry, add a backtrace, a copy of your sysconfig/proxy file and some cheese (Want to make a fondue). [Dominique Leuenberger in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org