Mailinglist Archive: opensuse-factory (564 mails)

[Christian Boltz <opensuse@xxxxxxxxx>]

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx