[opensuse] starting the virtualbox virtual machines automatically
Hello, I have a server configured as virtualbox home. The main purpose of this server is to host virtual machines. So It have to stop gracefully and restart the machines when stopping (for example if main power supply fail, and the UPS go low). I did this with init scripts and headless virtualbox scripts. I have to update to 12.1 and don't know how to manage this with systemd. I know 12.1 is init compatible, but I would prefere to be full systemd compatible asap any clue? link to a doc is ok thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Hello,
I have a server configured as virtualbox home.
The main purpose of this server is to host virtual machines. So It have to stop gracefully and restart the machines when stopping (for example if main power supply fail, and the UPS go low).
I did this with init scripts and headless virtualbox scripts.
I have to update to 12.1 and don't know how to manage this with systemd.
I know 12.1 is init compatible, but I would prefere to be full systemd compatible asap
any clue? link to a doc is ok
http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Google - http://www.google.com/search?q=creating+systemd+services -- Per Jessen, Zürich (0.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/12/2011 09:54, Per Jessen a écrit : good, thanks However I see in:
Google - http://www.google.com/search?q=creating+systemd+services
"Create the service file # vi /lib/systemd/system/radinfo.service" I feel very bad writing anything myself in /lib! (let alone for backup purpose). But I see a "/etc/systemd/system" folder. May I write my service file there? thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd said the following on 12/26/2011 06:57 AM:
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc? How about /usr/lib or /usr/bin? If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it. My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d. -- "You don't concentrate on risks. You concentrate on results. No risk is too great to prevent the necessary job from getting done." -- Charles Yeager. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/12/2011 14:16, Anton Aylward a écrit :
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
and it's an other place to backup. I always backup /home and /etc here most if not all the scripts and config reside. Spread configs all over the system is not a good idea.
How about /usr/lib or /usr/bin?
it's not a binary
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
well, in openSUSE there is a folder in /etc, I wonder if it's not done for such things - I lt /lib for application originated ones
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
it's not a matter of screwing my system than maintaining my system over time, backing it up, etc. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd said the following on 12/26/2011 09:18 AM:
Le 26/12/2011 14:16, Anton Aylward a écrit :
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
and it's an other place to backup. I always backup /home and /etc here most if not all the scripts and config reside. Spread configs all over the system is not a good idea.
Well, there is that, but the reality is that the configs are all over the place. If you run chrooted DNS for example, the stuff in in /var/lib or somewhere like that. If you run a web server then you have config stuff under /srv. If you run KDE and KDM then you have stuff in /usr/share/kde4/config/kdm/kdmrc. If you've installed global versions of new icon sets, new screen savers, new desktop effects, new fonts, other than though a repository/rpm, you'll have no record of them other than if you keep written logs. And then there's that bloody awful stuff about flash .. As they say ... "In an Ideal World ..." But "Reality Bites".
How about /usr/lib or /usr/bin?
it's not a binary
I'm sorry, what's that got to do with things? There are files in both that are shell scripts, data, gifs, INI files, try running file /usr/lib/* /usr/lib/*/* | \ egrep -v "ELF|symbolic|directory|archive|libtool|DLL"
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
well, in openSUSE there is a folder in /etc, I wonder if it's not done for such things - I lt /lib for application originated ones
Have you read the MAN page? Or run 'strings' on /bin/systemd (which shows up a few more places it looks for config like under /usr/local) or looked at the source? Have you seen the part of the man page where it says The systemd system manager reads unit configuration from various directories. Packages that want to install unit files shall place them in the directory returned by pkg-config systemd --variable=systemdsystemunitdir. Other directories checked are /usr/local/share/systemd/system and /usr/share/systemd/system. User configuration always takes precedence. pkg-config systemd --variable=systemdsystemconfdir returns the path of the system configuration directory. Packages should alter the content of these directories only with the enable and disable commands of the systemctl(1) tool.
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
it's not a matter of screwing my system than maintaining my system over time, backing it up, etc.
Over the decades I've seen more and more migrate to /etc, even if only as symlinks :-/ But new stuff comes along and makes a mockery of all that. I quote some examples above. There's always good reasons. For example, in a reasonably ideal world, /etc/should be, if not mounted on a RO file system, the severely access restricted -- root only. But in practice, many of those things need to be dynamically re-written. The Named files for example. Life is possible without root, but it takes juggling of the /etc/group file and access permissions and stuff and stuff and not everyone can grok it. So we end up with "the mess we're in". They say the road to hell is paved with good intentions; the path that led us here is full of good justifications for each decision. One way of looking at the way SystemD works is that what's in /etc/systemd/system/ are not the control files. They all live in /lib/systemd anyway. What /lib/systemd amounts to is a library and the items are enabled by having a link to them in /etc/systemd/ By this reasoning you should put your file in /lib/systemd and have a symlink in /etc/systemd Take a look at the files under /etc/systemd/system/ Apart from the system.conf they are all symlinks. /lib/systemd is where the files actually live. Much as I hate to admit it, the Windows Registry does at least mandates all being in one place, but then again, it has a lot of undocumented crud compared to text file and still has many people and applications (not least of all malware) fiddling in it. -- "A PICTURE IS WORTH A THOUSAND WORDS--But it uses up a thousand times the memory." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/12/2011 16:14, Anton Aylward a écrit :
Well, there is that, but the reality is that the configs are all over the place.
you are right, and I have to read you post more than once to understand all, but thanks for your hints, I will make my honey from that :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/26/2011 8:16 AM, Anton Aylward wrote:
jdd said the following on 12/26/2011 06:57 AM:
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
How about /usr/lib or /usr/bin?
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
Don't listen jdd. Your point was perfectly clear to normal people and your guess was correct. https://wiki.archlinux.org/index.php/Systemd#How_do_I_make_a_custom_unit_fil... And here I thought _I_ was an ass. And contrary to his later post, configs _that matter_ are not "all over the place". They are in very few and well known places, and most everything that isn't either in /etc or /home are dynamically generated from, or reading, something that IS. And those few things that qualify as host-specific manual (won't happen automatically) configuration that may exist outside of /etc or /home on a poorly managed system, do not justify abandoning the best practices that always strive towards sane organization. /srv is content not config. You already know to back up all data dirs, and rpm already knows not to overwrite anything in data dirs. /usr/share may have hand-installed stuff, but if so that's just sloppy thoughtless administration, or evidence of a package that needs improvement so that it will install it's own things in /usr/share but also look in /usr/local, /home, etc for user-supplied stuff. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/26/2011 03:01 PM:
On 12/26/2011 8:16 AM, Anton Aylward wrote:
jdd said the following on 12/26/2011 06:57 AM:
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
How about /usr/lib or /usr/bin?
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
Don't listen jdd. Your point was perfectly clear to normal people and your guess was correct.
https://wiki.archlinux.org/index.php/Systemd#How_do_I_make_a_custom_unit_fil...
Its all very well to say "The unit files in /etc/systemd/system take precedence over the ones in /lib/systemd/system", but go look. The files in /etc/systemd/system/ are symlinks to ones in /lib/systemd/system/ So its possible that at some future time you do a restore of the backup of the /etc/ tree and something in that is a symlink to a /lib/systemd/system/ file that no longer exists. How will the SystemD process like that?
And contrary to his later post, configs _that matter_ are not "all over the place". They are in very few and well known places, and most everything that isn't either in /etc or /home are dynamically generated from, or reading, something that IS.
With a few exceptions (see below) that's true, but misses the point. The point is that for better or worse there *IS* dynamically generated stuff in other places. I'll grant you that new, virgin, out of the box system doesn't have a lot of what I'm talking about, but a mature, multi-user system does. A poster-boy example here is Named. Its not needed on a passive workstation once /etc/resolv.conf has been filled in to point to a DNS server. But if the host is serving dns requests, that is it is running named and named ha been securely configured - aka chrooted - then its actually elsewhere. Yes that elsewhere could be /etc/chroot/named but for some reason most systems I've used put it under /var/lib/named/. Come to think of it, there's a lot of dynamically generated stuff under /var/lib that I'd back up: the spamassassin database files, rpm and zypper stuff and more. Its not quite the static config you expect in /etc, but it *is* config in that it determines the state of the machine as a working entity, how it differs from baseline install. Yes, it you have custom fonts and stuff, they can end up under $HOME, that's if you have a single use machine. But if you have a server and the /use/share, for example, is shared via NFS so that all the workstations can benefits from additional features (such as fonts, icons and so forth), then the changes over and above the installation baseline should go there rather that in ~/.fonts/ or ~/.icons/ So yes, Brian, you are right in the specialized case.
And those few things that qualify as host-specific manual (won't happen automatically) configuration that may exist outside of /etc or /home on a poorly managed system, do not justify abandoning the best practices that always strive towards sane organization.
John Barth has a great line in one of his works: "Reality is a nice place to visit, but I wouldn’t want to live there". Many of us don't have the choice.
/srv is content not config. You already know to back up all data dirs,
I sincerely hope you do backup /srv - or wherever. There's config in that content. Take a look at what's under /etc/httpd/ More symlinks? When I installed some applications the config appeared under /etc/httpd/config.d/ but in reality that was a symlink to the real files under /srv How does your backup work? Is it a tree-walker based on find? Does it follow symlinks? Or does it take snapshots of file systems?
/usr/share may have hand-installed stuff, but if so that's just sloppy thoughtless administration,
No, it may be good administration, with /usr/share on the file server to make sure all the workstations receive the benefit of things there, as I described above.
or evidence of a package that needs improvement so that it will install it's own things in /usr/share but also look in /usr/local, /home, etc for user-supplied stuff.
Or KDM that is stupid in that it puts the config file kdmrc in. /usr/share/kde4/config/kdm/kdmrc So what else is in /usr/share/kde4/config/ ? They seem like templates to me, but kdmrc is not something to be copied to ~/.kde4/ since it is used by the system before login. Yes it should be in /etc/<something> but it isn't and any changes you make, customization[1] are there in /usr/share/ Reality bites. [1] e.g. restricted access warnings in accordance with corporate policy and legal advice. See http://www.unifiedcompliance.com/matrices/live/01742.html -- "...there is no reason anyone would want a computer in their home." Ken Olson, President, Chairman, and Founder of DEC, 1977 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/26/2011 4:19 PM, Anton Aylward wrote:
Brian K. White said the following on 12/26/2011 03:01 PM:
On 12/26/2011 8:16 AM, Anton Aylward wrote:
jdd said the following on 12/26/2011 06:57 AM:
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
How about /usr/lib or /usr/bin?
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
Don't listen jdd. Your point was perfectly clear to normal people and your guess was correct.
https://wiki.archlinux.org/index.php/Systemd#How_do_I_make_a_custom_unit_fil...
Its all very well to say "The unit files in /etc/systemd/system take precedence over the ones in /lib/systemd/system", but go look. The files in /etc/systemd/system/ are symlinks to ones in /lib/systemd/system/
So its possible that at some future time you do a restore of the backup of the /etc/ tree and something in that is a symlink to a /lib/systemd/system/ file that no longer exists. How will the SystemD process like that?
And contrary to his later post, configs _that matter_ are not "all over the place". They are in very few and well known places, and most everything that isn't either in /etc or /home are dynamically generated from, or reading, something that IS.
With a few exceptions (see below) that's true, but misses the point. The point is that for better or worse there *IS* dynamically generated stuff in other places.
I'll grant you that new, virgin, out of the box system doesn't have a lot of what I'm talking about, but a mature, multi-user system does.
A poster-boy example here is Named. Its not needed on a passive workstation once /etc/resolv.conf has been filled in to point to a DNS server. But if the host is serving dns requests, that is it is running named and named ha been securely configured - aka chrooted - then its actually elsewhere. Yes that elsewhere could be /etc/chroot/named but for some reason most systems I've used put it under /var/lib/named/.
Come to think of it, there's a lot of dynamically generated stuff under /var/lib that I'd back up: the spamassassin database files, rpm and zypper stuff and more. Its not quite the static config you expect in /etc, but it *is* config in that it determines the state of the machine as a working entity, how it differs from baseline install.
Yes, it you have custom fonts and stuff, they can end up under $HOME, that's if you have a single use machine. But if you have a server and the /use/share, for example, is shared via NFS so that all the workstations can benefits from additional features (such as fonts, icons and so forth), then the changes over and above the installation baseline should go there rather that in ~/.fonts/ or ~/.icons/
So yes, Brian, you are right in the specialized case.
And those few things that qualify as host-specific manual (won't happen automatically) configuration that may exist outside of /etc or /home on a poorly managed system, do not justify abandoning the best practices that always strive towards sane organization.
John Barth has a great line in one of his works: "Reality is a nice place to visit, but I wouldn’t want to live there". Many of us don't have the choice.
/srv is content not config. You already know to back up all data dirs,
I sincerely hope you do backup /srv - or wherever.
There's config in that content. Take a look at what's under /etc/httpd/ More symlinks? When I installed some applications the config appeared under /etc/httpd/config.d/ but in reality that was a symlink to the real files under /srv
How does your backup work? Is it a tree-walker based on find? Does it follow symlinks? Or does it take snapshots of file systems?
/usr/share may have hand-installed stuff, but if so that's just sloppy thoughtless administration,
No, it may be good administration, with /usr/share on the file server to make sure all the workstations receive the benefit of things there, as I described above.
or evidence of a package that needs improvement so that it will install it's own things in /usr/share but also look in /usr/local, /home, etc for user-supplied stuff.
Or KDM that is stupid in that it puts the config file kdmrc in. /usr/share/kde4/config/kdm/kdmrc So what else is in /usr/share/kde4/config/ ? They seem like templates to me, but kdmrc is not something to be copied to ~/.kde4/ since it is used by the system before login. Yes it should be in /etc/<something> but it isn't and any changes you make, customization[1] are there in /usr/share/
Reality bites.
Dynamically generated stuff doesn't matter. It is generated dynamically. ...you know...from configs, generally found in /etc. Various chroot-able services create and maintain/update the chroot environment under /var because that is exactly what /var is for. That stuff is generated and updated automatically and on-the-fly from data in /etc Mature multiuser? Uptime doesn't matter. I have 6 or 7 year old boxes that have been actually UP for over 3 years, that have over 200 login shell interactive users. Not just narrow focus specialized web servers but application servers running several main software apps as well as web/ftp/mail/fax serving all as part of the main app. And they have just about nothing that is host-specific that isn't in /etc, /home, srv, and a few application-specific data directories of our own. Everything else can get flushed with a new install or upgrade. I don't even put things in /usr/local any more except disposable stuff like using /usr/local/src for local osc builds for maintaining packages in obs. It's a simple matter to have been bitten by upgrades a few times way back when you had your first unix box, and then after that you just avoid shooting yourself in the foot. Any time something comes up that would otherwise involve writing some custom file into any system directory, I simply don't do it. I create or modify a package and install that package, and/or I figure out how to relocate the custom part to someplace sane, and usually there is already some means to do that and all I have to do is bother to use it. I haven't yet found anything that can't be made generic and portable even if it's crappy 3rd party commercial software that was not organized sanely to begin with. I don't see what the issue is with systemd. Any files that are provided in /etc in the form of symlinks to files in /usr, are simply files you shoulld elect not to customize. You write new ones in /etc. What's the problem? Or are you saying whole directories are symlinked and they are directories that you are supposed to write new user created files into because there is no other dedicated directory for that? If the systemd package really has some glaring failing like that, well there are no shortage of problems with systemd as it's a new package and still half baked. So that would just be one more example of why it's still a poor package even if it's a good idea in the long run. Sysv init works the other way, where the real script is in /etc/init.d and the /etc/rc3.d and /usr/sbin/rcfoo are just symlinks, so that when you back up /etc, you actually get the stuff that matters. You don't want to blindly restore all that onto a new box any more than you want to blindly restore the rest of /etc, but that's not the point. It might be nice but the real important thing is the data needed to recreate the system is not lost. Again, just because there is crap software out there that doesn't provide full seperation and organization, doesn't justify not even trying wherever else you can. If I didn't try, sure, my systems would be plain unmanageable. I'd have crap all over the place and I could never migrate or update anything without it being an all day project just for one little box. But luckily, although I am still stupid in many ways, I'm at least less stupid about this because when I back up just /etc, /srv, 3 other directories particular to us, and /home (and really I don't even need /home but I'll grant that most people that have users, have user content in /home) that's it. That's all I need. Everything else is provided by packages and/or dynamically generated when various services and apps run. And that was _mostly_ because of the way the system was already designed, not because I hacked mine to be super portable & manageable. All I did was make use of the facilities and schemes that are already there just for this purpose. The things I had to hack were only 3rd party commercial software that barely supports linux at all let alone any particular distribution. So they come with install directions that are so crude as to not even work if you actually tried to follow them verbatim. But even they were just a matter of doctoring up installer, wrapper and start scripts. There are things like that kdmrc script that could be customized, but, "don't do that". Do it elsewhere. That script, or whatever reads it, probably already tries to source in something from elsewhere (/home, /etc) along the way, go edit that instead. That script is probably mostly for system level customization, ie, suse tweaks theirs different than ubuntu tweaks theirs, and neither is related to how a user tweaks theirs. If any user changable settings end up getting stored there, it's probably nothing that matters, no sticky notes or bookmarks, just last selected desktop, last login name used etc. I don't use kdm so it's possible it does store something that isn't utterly transient and insignificant there, but even in that unlikely case, it just means that's a candidate for improvement. It does not mean "There are configs and user files all over the place anyways so it's fine to write your own hand made files in /lib/foo" Reality does bite, but for every 1000 times reality might bite, 990 of theme are avoidable. So in reality, reality mostly only only bites when you let it. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/26/2011 06:42 PM:
Dynamically generated stuff doesn't matter. It is generated dynamically. ...you know...from configs, generally found in /etc.
Maybe it is, in some cases. But I don't think that is an assertion that can be universally applied.
Various chroot-able services create and maintain/update the chroot environment under /var because that is exactly what /var is for. That stuff is generated and updated automatically and on-the-fly from data in /etc
I used the example of DNS. You may choose to put the information that is in the DNS in /etc/hosts as well and make your /etc/nsswitch look for files before using dns when resolving, but there are suppositions in that, most notably that everything in your DNS is in your hosts file. That may not be the case. It may be the case that you are acting as a secondary for another domain and that is updating the information in the chrooted area, /var/lib/named in my case, and that information is not, cannot be, derived from what's in my /etc/hosts. It may not even be in the /etc/hosts of the DNS server of the domain I'm acting as a secondary for. I realise that not everyone has arrangements for acting as a dns secondary, but it does illustrate my point. I'm sure that given time to dig I could come up with other examples where you need to backup other parts of the tree or where other parts of the tree have config that is not reconstructable from what's in /etc. And I think that just because there is a symlink from /etc/<somehwere> to the actual config data in /srv or /var doesn't validate your point.
Mature multiuser? Uptime doesn't matter. I have 6 or 7 year old boxes that have been actually UP for over 3 years, that have over 200 login shell interactive users. Not just narrow focus specialized web servers but application servers running several main software apps as well as web/ftp/mail/fax serving all as part of the main app. And they have just about nothing that is host-specific that isn't in /etc, /home, srv, and a few application-specific data directories of our own. Everything else can get flushed with a new install or upgrade. I don't even put things in /usr/local any more except disposable stuff like using /usr/local/src for local osc builds for maintaining packages in obs.
Some of that's your decision. My decision is to use KDE and KDM an that means I'm living with kdmrc in /usr/share. Can you tell me that there are no symlinks under /etc/ on any of your systems that lead to /var, /use or /svc? This is why I asked about your backup method.
It's a simple matter to have been bitten by upgrades a few times way back when you had your first unix box, and then after that you just avoid shooting yourself in the foot.
BTDT and I hate it and do what I can about it. Like when I back up /etc I make sure that I *AM* following symlinks. I also take dumps of the RPM database so I know what I have installed, but that database doesn't live in /etc does it? In an ideal world I could freeze /etc (and /bin and /sbin and more) by having the rootfs ro, and seperate /var, /svc, /home and swap fs. You can't do that with Windows because of the way the registry is implemented. And that's why some things that need to be dynamic are in /var. OK, so its impractical; how would I add users? Hosts? Well, there's LDAP, and guess where the LDAP database with the list of users lives? If not in /var then off on another machine :-)
Any time something comes up that would otherwise involve writing some custom file into any system directory, I simply don't do it. I create or modify a package and install that package, and/or I figure out how to relocate the custom part to someplace sane, and usually there is already some means to do that and all I have to do is bother to use it.
Ah, so what you're saying is that in the case of something like KDM, where I have to live with kdmrc being in /usr/share you would down load the source, change the source so that kdmrc now lives in /etc/, recompile and rebuild the package and run with this new package. Well that's one way of getting around the problem.
I haven't yet found anything that can't be made generic and portable even if it's crappy 3rd party commercial software that was not organized sanely to begin with.
No doubt you can do the reverse of what is in /etc right now. You can create the config in /etc and have a symlink from where the 3rd party software expects it to be back to the real file under /etc.
I don't see what the issue is with systemd. Any files that are provided in /etc in the form of symlinks to files in /usr, are simply files you shoulld elect not to customize. You write new ones in /etc. What's the problem? Or are you saying whole directories are symlinked and they are directories that you are supposed to write new user created files into because there is no other dedicated directory for that?
Ah, many questions. Symlinking a directory is not good practice, its very inflexible. But one way of viewing it is yes, there are directories under /etc/systemd/system that contain nothing but symlinked files. Try running find -P /etc/systemd/system -type f -print to see what files are NOT symlinked. As for dedicated .. well the man page mentions Packages that want to install unit files shall place them in the directory returned by pkg-config systemd --variable=systemdsystemunitdir It also says Packages should alter the content of these directories only with the enable and disable commands of the systemctl(1) tool What directories? Well the one returned by the pkg-config command and ... Other directories checked are /usr/local/share/systemd/system and /usr/share/systemd/system. It then says, rather confusingly User configuration always takes precedence. The best I can make of that is that there is also /etc/systemd/user but nothing seems to be there. There is no /lib/systemd/user is there?
If the systemd package really has some glaring failing like that, well there are no shortage of problems with systemd as it's a new package and still half baked. So that would just be one more example of why it's still a poor package even if it's a good idea in the long run.
The main problem I see people having with SystemD is not reading the man pages and not googling for what is written about it.
Again, just because there is crap software out there that doesn't provide full seperation and organization, doesn't justify not even trying wherever else you can.
I agree, but that doesn't mean you should create security exposures or fail to back up user generated and dynamic data. In the limiting case, one cold argue, that given the installation CD and what's in /etc, such as the list of repositories, you don't need to back up anything except /home and /srv. If you loose your system you can get a new one, a new disk, install from the CD, slap on the old /etc and /home and do a zypper update. Well jolly good luck to you. I'll take more complete backup and be "back up" in a fraction the time. Because for a lot of businesses, "time is money". Of course offloading services, DNS, DHCP, LDAP, database ... means you only have to backup elsewhere, and using the snapshot mechanism of LVM makes backups a lot easier. Snap! Now image that to a DVD. Easy. Fast.
There are things like that kdmrc script that could be customized, but, "don't do that". Do it elsewhere. That script, or whatever reads it, probably already tries to source in something from elsewhere (/home, /etc) along the way, go edit that instead.
Um, this is the bit that does the login, so it simply cannot do anything with a specific user's home. Think about it.
That script is probably mostly for system level customization, ie, suse tweaks theirs different than ubuntu tweaks theirs, and neither is related to how a user tweaks theirs.
I can't comment on that; I only have RPM-based system, uses, fedora, mandriva. But on those systems, the kdmrc file defines what the login screen looks like, the background, position of the login prompts and more.
If any user changable settings end up getting stored there, it's probably nothing that matters, no sticky notes or bookmarks, just last selected desktop, last login name used etc.
A LOT about the configuration of the login process gets stored there! Go look, or google ... http://slackware.osuosl.org/slackware-10.0/source/kde/kdebase/config/kdmrc
I don't use kdm so it's possible it does store something that isn't utterly transient and insignificant there, but even in that unlikely case, it just means that's a candidate for improvement.
Take it from me or read the above; there's a lot in there. But yes, it could well be under /etc and on my fedora system there is a /etc/kde/kdm/kdmrc The irony is that there is a /usr/share version as well. And when I look at the binary, /usr/libexec/kde4/kdm_config, which is the part of kdm that reads the config, it references /usr/share/config/kdm/kdmrc and /var/lib/kdm. There is no mention of /etc. Previous user lives in /var/lib/kdm/kdmsts : :::::::::::::: [PrevUser] :0=anton So iyts a case of could be ... should be ... but isn't really.
It does not mean "There are configs and user files all over the place anyways so it's fine to write your own hand made files in /lib/foo"
I didn't say that. I didn't say anything like that. I didn't say anything that implied that. At worst, I said "In an ideal world". I said that I have to live with a reality that isn't the ideal world. I never advocated such arbitrariness. I'd love to see all config in /etc and all chrooted stuff well documented. I could then write perl scripts to parse all that and automated more and more of sysadmin :-)
Reality does bite, but for every 1000 times reality might bite, 990 of theme are avoidable. So in reality, reality mostly only only bites when you let it.
Not all of us are able - or have the time out - to re-package and hack away. What we should do is put pressure on the developers to clean up their practices. -- The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten. --Kathleen Byle, Sandia National Laboratories -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/26/2011 9:12 PM, Anton Aylward wrote: kdmrc in fact turns out to posses 2 properties I posited. 1) There is in fact a file in /etc that generates it or is layered onto it. Or rather, is supposed to. 2) The kdm package has been broken for years and people have been requesting it be fixed for years, specifically that kdmrc be moved back into /etc where any such file belongs because the /etc/sysconfig file is insufficient. It was there originally, then coolo@suse moved it. As well as a different problem that the suse/yast kdmrc editor and sysconfig overlay/regenerator is broken and should be disabled, after which the kde native editor works properly. http://lists.opensuse.org/opensuse-factory/2006-09/msg00022.html http://lists.opensuse.org/opensuse-kde/2009-11/msg00168.html https://bugzilla.novell.com/show_bug.cgi?id=267903 So you're right. You do need that file. It qualifies as system config data that isn't sourced from /etc. But only because the kdm package is faulty, not because it's the official intended behavior.
It does not mean "There are configs and user files all over the place anyways so it's fine to write your own hand made files in /lib/foo"
I didn't say that. I didn't say anything like that. I didn't say anything that implied that.
What you said to jdd looked exactly like that to me. But I'm thinking maybe you just didn't hear him the same way I did. I didn't think jdd thought he would break hist system, or that he wouldn't know how to manually write a file in /lib and get the job done, just that he thought it was probably bad practice in general, and not something one should officially recommend or document, and one of those reasons was it breaks the expectation that backing up /etc will back up everything in the way of host config, and I absolutely agree on both points. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/27/2011 03:19 AM:
So you're right. You do need that file. It qualifies as system config data that isn't sourced from /etc. But only because the kdm package is faulty, not because it's the official intended behavior.
That's what I meant when I spoke of "reality bites" and the contrast with the ideal world situation. I'd like things to be as you describe and have been advocating it for decades and have seen it progress but as you say, sometimes its two-steps-forward/one-step-back. Perhaps, as the http://docs.kde.org/stable/en/kdebase-workspace/kdm/configuring-kdm.html page says, using $KDEDIR is the root of this evil since it can be set to /usr instead of /etc. The official intended behaviour is "either/or". Bad move! But honestly, while each and everyone one of us _could_ install the development packages, down load the sources for KDE, recompile .. sorry, what was that about the build service? Is someone going to volunteer? -- How come wrong numbers are never busy? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/26/2011 06:42 PM:
I don't use kdm so it's possible it does store something that isn't utterly transient and insignificant there, but even in that unlikely case, it just means that's a candidate for improvement.
Well when I googled I found http://docs.kde.org/stable/en/kdebase-workspace/kdm/configuring-kdm.html As you said, distributions can put stuff where they want: $KDEDIR can be /usr or /etc But I want to emphasise this passage: Since kdm must run before any user is logged in, it is not associated with any particular user. Therefore, it is not possible to have user-specific configuration files; all users share the common kdmrc. -- "Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction, and skillful execution; it presents the wise choice of many alternatives." - W. Foster. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/12/2011 22:19, Anton Aylward a écrit :
Reality bites.
yes and no. I really care of script *I* write, and sometime in a hurry (that mean I don't always have a hardcopy :-(). And I prefere to have it in /etc, because it is usually easy to backup (compressed, it do not take much room). The problem is never the backup, but the restore. In my experience, cases where you simply restore a backup never happen. When hardware fail, the new one is never identical. Even apparently identical (byte wise) backup do not restore on the very hardware it was done - only a ghost will work and on a remote server it's often not possible (my last reinstall what due to this problem - I could never restore the system partition, backed on the data one :-(. so I try to have all user data backed and reinstall a system from scratch when something break. for other cases, raid is a solution I don't need. so I have to adapt my config, mostly copying old config files and adapting to new systems. I now have to adapt a 11.2 working system to systemd. I only have to take care of the virtual machines restart as this changed, but who knows what will change next time. and I don't have the choice to keep the old config, 11.2 is no more maintained jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd said the following on 12/26/2011 06:46 PM:
Le 26/12/2011 22:19, Anton Aylward a écrit :
... [snip] ..
The problem is never the backup, but the restore. In my experience, cases where you simply restore a backup never happen.
When hardware fail, the new one is never identical. Even apparently identical (byte wise) backup do not restore on the very hardware it was done - only a ghost will work and on a remote server it's often not possible (my last reinstall what due to this problem - I could never restore the system partition, backed on the data one :-(.
Back in the bad old SCO days when disks were small, yes it was a problem. These days with Big Disks the solution is to create a LVM partition that is a staging area and restore into that. Now if you did absolute backups you are still buqqered. Learn not to do that. But if you have relative backups you can restore that old "etc/" onto a scratch fs and then selectively move what you need, things like /etc/hosts, the password/group files and other things you have customised, across to the real /etc.
I now have to adapt a 11.2 working system to systemd. I only have to take care of the virtual machines restart as this changed, but who knows what will change next time.
That's why I have a scrappy old SallyAnne Special with a scrappy old disk and lots of nfs mounts and a working and stable Fedora 15 with a working and stable version of SystemD (all those things people are stumbling over on 12.1 I have working fine on this F-16 (soon to be F-16)) so I can learn how it is supposed to work on a system that does work, rather than battle a system (12.1) that doesn't work. There are many things about Fedora I don't like, YUM being there out in front! I'll be glad when openSuse 12.2 comes out :-) In the mean time I can decompress with a working fine 11.4 system on my 2005 vintage Compaq desktop-replacement laptop.
and I don't have the choice to keep the old config, 11.2 is no more maintained
You could have upgraded to 11.4. That would have been smoother, less traumatic. The 11.4 works well and runs the latest kde :-) -- To invent, you need a good imagination and a pile of junk. -- Thomas A. Edison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 27/12/2011 03:29, Anton Aylward a écrit :
These days with Big Disks the solution is to create a LVM partition that is a staging area and restore into that.
? if disk fail, all the lvm is lost. I work (in fact I intend to work, this is a new system) with a minimal server as gateway. Only have to backup SuSEfirewall config, and all the reste on virtual machines, very easy to backup the hole machine to an other computer. I even intend to have this second computer switchable to have an instant replacement
/etc/hosts, the password/group files and other things you have customised, across to the real /etc.
yes it's the way I use it
stumbling over on 12.1 I have working fine on this F-16 (soon to be F-16)) so I can learn how it is supposed to work on a system that does work, rather than battle a system (12.1) that doesn't work.
well... I know nothing about fedora...
In the mean time I can decompress with a working fine 11.4 system on my 2005 vintage Compaq desktop-replacement laptop.
you know, the server I build is there to replace a celeron year 2000 server with 128Mb (mega bytes!) ram and 15Gb HDD that I have to stop because my provider do not want it anymore (it still works :-). I planned this change 2 years ago, and setup openSUSE 11.2 - it works. but it's no more maintained. quite curiously, very old computer that can't be upgraded are not attacked (I beg new rootkit do not work on so old hardware), when new one are.
You could have upgraded to 11.4. That would have been smoother, less traumatic. The 11.4 works well and runs the latest kde :-)
I know that, but rignt now my server is not in production, so I can work on it easily, I don't want to do this again in one year thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd said the following on 12/27/2011 04:36 AM:
Le 27/12/2011 03:29, Anton Aylward a écrit :
These days with Big Disks the solution is to create a LVM partition that is a staging area and restore into that.
?
You were talking about the problems with RESTORE. So was I. On the new system, have a partition that the old "etc/" is restored into rather than overwriting the /etc on the newly installed system. That's why you want relative backups not ones with absolute locations.
if disk fail, all the lvm is lost.
stumbling over on 12.1 I have working fine on this F-16 (soon to be F-16)) so I can learn how it is supposed to work on a system that does work, rather than battle a system (12.1) that doesn't work.
well... I know nothing about fedora...
Neither did I before I decided to install it to learn about how SystemD should work.
In the mean time I can decompress with a working fine 11.4 system on my 2005 vintage Compaq desktop-replacement laptop.
you know, the server I build is there to replace a celeron year 2000 server with 128Mb (mega bytes!) ram and 15Gb HDD that I have to stop because my provider do not want it anymore (it still works :-).
Yup. I have one of those that I use to support my monitor and raise it to eye level :-) It runs IPCop, and very nicely thank you!
You could have upgraded to 11.4. That would have been smoother, less traumatic. The 11.4 works well and runs the latest kde :-)
I know that, but rignt now my server is not in production, so I can work on it easily, I don't want to do this again in one year
It all comes down to this: do you need a working system with no complication RIGHT NOW? If the answer to that is "yes" then 11.4 is _an_ answer and 12.1 is _not_. But then again, using something other than openSuse is also _an_ answer. I'm not claiming fedora is perfect, but they did pioneer SystemD and one -15 it works well and has none of the complications and has proven valuable for learning how SystemD was meant to work. I do prefer openSuse and will be glad when 12.2 or 12.3 arrives :-) But I'm in no hurry to use 12.1 on a production system. -- Conservatism is the blind and fear-filled worship of dead radicals. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 27/12/2011 13:19, Anton Aylward a écrit :
You were talking about the problems with RESTORE. So was I. On the new system, have a partition that the old "etc/" is restored into rather than overwriting the /etc on the newly installed system.
oh, yes, of course, I always do. I always have a spare partition on my system for such purpose. I had problem in the past with hosted server that I could only admin through the provider manager - I never could restore it (never booted again), but this proveider have special hardware and fitted kernel. It's very handy because it takes care of kernel updates, but this make backup/restore of the system tricky and he only keep available the very last distro (I couldn't restore 11.3 because the last one was 11.4). but the one I sepak of now is available at hand in front of me, so much easier to manage :-)
You could have upgraded to 11.4. That would have been smoother, less traumatic. The 11.4 works well and runs the latest kde :-)
I don't need kde at all, so yes, this is a solution. and once it's done, upgrade to 12.1 works easily thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 26/12/2011 09:54, Per Jessen a écrit : good, thanks
However I see in:
Google - http://www.google.com/search?q=creating+systemd+services
"Create the service file # vi /lib/systemd/system/radinfo.service"
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
May I write my service file there?
That would be my immediate guess. I would expect /lib/systemd to be meant for vendor/systemd provided services, where /etc/systemd could be for locally provided services. Just a guess though. -- Per Jessen, Zürich (3.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Anton Aylward -
Brian K. White -
jdd -
Per Jessen