Re: Extending fcopy
On Thursday, 7. December 2006 22:45, Michael Tautschnig wrote: Hi all, Janning has proposed quite a few enhancements to fcopy lately. I think the resulting discussion should be bundled in a single thread and it should actually move to linux-fai-devel (@Janning: don't know, whether you are subscribed to this one already). Just to summarize, the suggestions were: - some -k/--keep option (which I'd rather call --keep-permissions :-) ) to retain the permissions of the file which should be overwritten (BTW: what should happen if there is no such file?) I'm not against the option, but in the an FAI context, IMHO one should now user:group:permission before overriding a file. If there are different from host to host, then either it's wrong or I better 'code' this exception in the installation scripts. - IMHO of course. - some way to return the number of files that were actually copied. That does not sound unix'ish IMHO. Why not the paths of the files copied are listed on stdout. Num is then just adding '| wc -l'. And stuff like: fcopy --whatever | while read file; do ... are still possible. Philosophical: I favour postinst scripts for all this, i.e. event based programming ;) When using FAI the first time the split of data below files and scripts using then scattered over the rest of fai/config was very hard to follow. Now I use fcopy recursive once and logic is in postinst files. And if something is missing I would first think about adding another event script like postinst and filemode. My objections were - Adding code to a mission-critical tool like fcopy is dangerous. - More options may confuse users. - The intended behaviour may be simulated using pre-/postinst scripts. In my opinion the first and the second are still valid, however, the third has been proven to be _really_ clumsy. So I guess these options should be added, if a proper patch can be provided. Maybe, but I like the idea of object (config file) and methods (scripts) being at the same place and not scattered throughout the fai/config tree somewhere (hidden) in scripts. In my (limited) experience it's easier to figure out _later_ when-why-what happens with the config file. Just my 2 euro cent, Achim Hoping for further discussion, Michael -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED]
Re: Extending fcopy
On Friday, 8. December 2006 13:47, Janning Vygen wrote:
Am Freitag, 8. Dezember 2006 11:29 schrieben Sie:
On Thursday, 7. December 2006 22:45, Michael Tautschnig wrote:
- some -k/--keep option (which I'd rather call --keep-permissions :-) )
to retain the permissions of the file which should be overwritten (BTW:
what should happen if there is no such file?)
I'm not against the option, but in the an FAI context, IMHO one should now
user:group:permission before overriding a file. If there are different
from host to host, then either it's wrong or I better 'code' this exception
in the installation scripts. - IMHO of course.
Why should i know the user:group:permission of a file like /etc/sudoers. I
know it is there i want to override it and want to keep the permissions of
the orignial file. to me, it sounds very naturally, just to copy the content
of a file and keep original permissions.
If a file permission get borked it will never be fixed by an softupdate.
In the case that it's not root:root 644 it has in most cases a special
reason. If the file is missing there noting to preserve, what to use then?
would be nice if a softupdate fixes it with right protections.
- some way to return the number of files that were actually copied.
That does not sound unix'ish IMHO. Why not the
paths of the files copied are listed on stdout. Num is then just adding
'| wc -l'. And stuff like: fcopy --whatever | while read file; do ...
are still possible.
your absolutely right and i already wrote it this way, but i did use a
different format fcopy already uses:
print fcopy: copied $sourcefile to $destfile\n ;
that also okay. grep of sed can be used to transform
i tried to use exit code, too:
exit code is 0: if one or more files were changed (content or permissions)
and no errors occured
exit code is 1: if no files were changed (content nor permissions) and no
warnings or errors occured
exit code is 2: warnings or errors occured plus description of exit code 1
exit code is 3: warnings or errors occured plus description of exit code 1
exit code is 4: on all other conditions (show Usage etc.)
this way you can say
fcopy ... /etc/postgresql /etc/init.d/postgresql restart || exit 1;
What do you think about using exit codes? First i sort it's not unix like,
but
diff does like this, too.
Add $? to your prompt and you'll see that much more apps do it like this ;)
So both methods can coexists with file list turned on (or off) with a file
an option.
Philosophical: I favour postinst scripts for all this, i.e. event based
programming ;) When using FAI the first time the split of data below
files and scripts using then scattered over the rest of fai/config
was very hard to follow. Now I use fcopy recursive once and logic is
in postinst files. And if something is missing I would first think
about adding another event script like postinst and filemode.
but if you have more than two (or more) config files for a daemon you need
two
(or more) postinst scripts which reloads the daemon. And the daemon is
reloaded twice and maybe even before the second file is copied which might
even include a security hole. Because the daemon is restarted with only one
file changed, then copying the second file before restarting again. i don't
like restarting a half-configured daemon.
Yeah, that's right. I didn't run into this yet (or didn't realize ;)
I _assume_ I would have added a cfggroup.desc/ tree with the correlated
files in it and used fcopy -r ... desc-postinst construct like you.
When it happened more often: groups/desc.{postinst,.d/,...}
plus a little wrapper script, that loops, calls fcopy -r and the scripts.
Achim
kind regards
janning
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [EMAIL PROTECTED]
Re: Extending fcopy
Am Freitag, 8. Dezember 2006 16:48 schrieben Sie: - some -k/--keep option (which I'd rather call --keep-permissions :-) [...] If a file permission get borked it will never be fixed by an softupdate. you don't need to use the -k (keep-permissions) option, so spftupdate can fix it. But why should it be broken anyway? In the case that it's not root:root 644 it has in most cases a special reason. If the file is missing there noting to preserve, what to use then? then use -M, -m or source file permissions as it is right now. [...] i tried to use exit code, too: [...] this way you can say fcopy ... /etc/postgresql /etc/init.d/postgresql restart || exit 1; What do you think about using exit codes? First i sort it's not unix like, but diff does like this, too. Add $? to your prompt and you'll see that much more apps do it like this ;) So both methods can coexists with file list turned on (or off) with a file an option. i switched this behaviour now after some tests. My patched fcopy now returns 0 if no files were changed or 1 if files were changed. I changed because if fcopy returns exit code 1 when nothing was changed it was propagated as the script exit code. But i am still not sure what is nicer, to return exit code 1 if files were changed or return exit code 1 if files were NOT changed. kind regards janning
