I wonder if I am alone in finding some of the developments in Fedora-16 actually make life harder for the user?
I'd take grub2 and systemctl as two examples. In each case I've read the documentation and understand the motivation behind these developments. But I remain unconvinced that the gains outweigh the disadvantages of methods that are much harder to configure and use.
I don't think this is just a matter of unfamiliarity. I think one can say objectively that the new methods are more complicated than those they replace.
As a crude measure of complication the new commands take longer to type than the old, eg "systemctl start openvpn@client.service" compared with "start service openvpn".
And the output of the new commands seems much more verbose than the old: eg compare the output of "systemctl -a" or "systemctl list-units" with that of "chkconfig --list".
Could anyone bringing in these changes have honestly answered "Yes" if asked whether the new method would simplify life for the user?
On Thu, 2012-03-22 at 12:56 +0100, Timothy Murphy wrote:
I wonder if I am alone in finding some of the developments in Fedora-16 actually make life harder for the user?
I'd take grub2 and systemctl as two examples. In each case I've read the documentation and understand the motivation behind these developments. But I remain unconvinced that the gains outweigh the disadvantages of methods that are much harder to configure and use.
I don't think this is just a matter of unfamiliarity. I think one can say objectively that the new methods are more complicated than those they replace.
As a crude measure of complication the new commands take longer to type than the old, eg "systemctl start openvpn@client.service" compared with "start service openvpn".
And the output of the new commands seems much more verbose than the old: eg compare the output of "systemctl -a" or "systemctl list-units" with that of "chkconfig --list".
Could anyone bringing in these changes have honestly answered "Yes" if asked whether the new method would simplify life for the user?
I'll say this. I recently went to read the grub2 documentation and found this product rather obtuse and complex. As an example trying to figure out the camparative roles of grub2-mkconfig and grub2-install. One would think that grub2-install wold have to run grub2-mkinstall but as far as I can see it doesn't. How confusing!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2012 01:05 PM, Aaron Konstam wrote:
I'll say this. I recently went to read the grub2 documentation and found this product rather obtuse and complex. As an example trying to figure out the camparative roles of grub2-mkconfig and grub2-install.
The grub2-mkconfig command processes the templates in /etc/ and the options specified in /etc/default/grub to generate a new grub config file (Normally read from /boot/grub/grub.cfg and symlinked into /etc/ as /etc/grub2.cfg).
It produces output on stdout. Redirect it to the file to update it.
This is covered in the info manual, section 20 "Invoking grub-mkconfig".
Updating the configuration with grub-mkconfig is analogous to editing /boot/grub/grub.conf on prior releases.
One would think that grub2-install wold have to run grub2-mkinstall but as far as I can see it doesn't. How confusing!
The grub2-install command installs the grub2 bootloader components to a drive. It's exactly analogous to grub 1.x's grub-install script and is documented in section 19 of the info manual, "Invoking grub-install".
You only need to do that once unless something has overwritten it (like another OS installer) or you replace disks.
You might also like to take a look at section 1.3, "Differences from previous versions" and section 3, and 3.1; "Installation" and "Installing GRUB using grub-install".
I can't stand the info manual format personally and I'd much rather have a well-written traditional man page but the information is there and quite clear imho.
Regards, Bryn.
On 22 March 2012 12:56, Timothy Murphy gayleard@alice.it wrote:
I wonder if I am alone in finding some of the developments in Fedora-16 actually make life harder for the user?
I'd take grub2 and systemctl as two examples. In each case I've read the documentation and understand the motivation behind these developments. But I remain unconvinced that the gains outweigh the disadvantages of methods that are much harder to configure and use.
I don't think this is just a matter of unfamiliarity. I think one can say objectively that the new methods are more complicated than those they replace.
As a crude measure of complication the new commands take longer to type than the old, eg "systemctl start openvpn@client.service" compared with "start service openvpn".
And the output of the new commands seems much more verbose than the old: eg compare the output of "systemctl -a" or "systemctl list-units" with that of "chkconfig --list".
Could anyone bringing in these changes have honestly answered "Yes" if asked whether the new method would simplify life for the user?
I'd agree that the systemctl syntax is clumsier. But on my machines, the boot time has reduced dramatically.
For grub2, one of the things I like is that it picked up the windows installation on the other disk, without any configuration on my part. It also picks up other linux installations on a multi-boot machine.
IMO the added functionality is worth the added complications.
Regards,
Chris
On Thu, Mar 22, 2012 at 10:42 AM, Chris Rouch chris.rouch@gmail.com wrote:
For grub2, one of the things I like is that it picked up the windows installation on the other disk, without any configuration on my part. It also picks up other linux installations on a multi-boot machine.
I just wish system-config-boot was updated to handle grub2. I still haven't figured out how to change which boot option is default so I can change it to XP on my work machine.
Thanks, RIchard
Am 22.03.2012 16:54, schrieb Richard Shaw:
On Thu, Mar 22, 2012 at 10:42 AM, Chris Rouch chris.rouch@gmail.com wrote:
For grub2, one of the things I like is that it picked up the windows installation on the other disk, without any configuration on my part. It also picks up other linux installations on a multi-boot machine.
I just wish system-config-boot was updated to handle grub2. I still haven't figured out how to change which boot option is default so I can change it to XP on my work machine
you really need a graphical UI for opening "/boot/grub2/grub.cfg" and simply change the line set default="0" tp 1,2,3.....?
why?
and yes you can ignore the "# DO NOT EDIT THIS FILE" as long you do not call "grub2-mkconfig" which is not needed usually
On Thu, 22 Mar 2012 16:58:24 +0100 Reindl Harald wrote:
and yes you can ignore the "# DO NOT EDIT THIS FILE" as long you do not call "grub2-mkconfig" which is not needed usually
The actual abomination with grub2 is the fact that the grub2-mkconfig tool exists. One of the main forces that led to the death of lilo was the ridiculous need to run extra tools after updating the files in order to actually make them take effect.
Now with grub2, we have the return of extra tools the docs and comments all say you are supposed to use, yet grubby doesn't use them, so it is even more confusing when you have edited /etc/default/grub and then you get a kernel update installed and none of the changes you made to /etc/default/grub actually appear.
Fedora should eradicate grub2-mkconfig and /etc/default/grub and remove the "do not edit this file" comment so there is really only one file to edit again and no confusing conflicting behavior.
On 22/03/12 16:27, Tom Horsley wrote:
Fedora should eradicate grub2-mkconfig and /etc/default/grub and remove the "do not edit this file" comment so there is really only one file to edit again and no confusing conflicting behavior.
Grub2 direction being currently discussed as part of this thread: https://lists.fedoraproject.org/pipermail/devel/2012-March/164428.html
On Thu, 22 Mar 2012, Tom Horsley wrote:
On Thu, 22 Mar 2012 16:58:24 +0100 Reindl Harald wrote:
and yes you can ignore the "# DO NOT EDIT THIS FILE" as long you do not call "grub2-mkconfig" which is not needed usually
The actual abomination with grub2 is the fact that the grub2-mkconfig tool exists. One of the main forces that led to the death of lilo was the ridiculous need to run extra tools after updating the files in order to actually make them take effect.
My suspicion is that we can look forward to something like autoconf for grub.
On Thu, Mar 22, 2012 at 10:58 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 22.03.2012 16:54, schrieb Richard Shaw:
On Thu, Mar 22, 2012 at 10:42 AM, Chris Rouch chris.rouch@gmail.com wrote:
For grub2, one of the things I like is that it picked up the windows installation on the other disk, without any configuration on my part. It also picks up other linux installations on a multi-boot machine.
I just wish system-config-boot was updated to handle grub2. I still haven't figured out how to change which boot option is default so I can change it to XP on my work machine
you really need a graphical UI for opening "/boot/grub2/grub.cfg" and simply change the line set default="0" tp 1,2,3.....?
why?
and yes you can ignore the "# DO NOT EDIT THIS FILE" as long you do not call "grub2-mkconfig" which is not needed usually
Well if you reordered your post you would answer your own question. Everything I have read says you shouldn't edit the config file directly so I was looking for the correct way to do it but I didn't see anything particularly helpful in /etc/default/grub.
Richard
Chris Rouch wrote:
I'd agree that the systemctl syntax is clumsier. But on my machines, the boot time has reduced dramatically.
I agree that boot time seems to have been reduced, at a guess about 15% in my case. However, I hardly ever re-boot, so any saving there was outweighed many times by the fact that I had to read what seemed like a very long tome to discover how to start openvpn. I still haven't discovered the equivalent of "chkconfig openvpn on" under the new dispensation.
But to return to boot-speed, how could using systemctl be any faster than an exactly equivalent command expressed in chkconfig terms? If the process could be speeded up in one case surely it could be speeded up in exactly the same way in the other case?
And even if it were true that the change lessened boot-time, in my view if a process runs twice as fast but it takes twice as long to work out how to get the process to run at all then there has been no improvement at all.
The value put on "user time", ie the time taken by a human being exercising his brain cells, should be 10^n times the value put on "machine time", where n is probably about 8.
I'd agree that the systemctl syntax is clumsier. But on my machines, the boot time has reduced dramatically.
I still haven't discovered the equivalent of "chkconfig openvpn on" under the new dispensation.
openvpn has special issues with systemd, but once you know the magic recipe, it works fine. See: https://bugzilla.redhat.com/show_bug.cgi?id=744244
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service \ /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
Replace "client" with "server" in each command if the computer is the openvpn server.
- Mike
Dr. Michael J. Chudobiak wrote:
openvpn has special issues with systemd, but once you know the magic recipe, it works fine. See: https://bugzilla.redhat.com/show_bug.cgi?id=744244
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service \ /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
Can you really claim that that is as easy as "chkconfig openvpn on"? It takes 10 times as long to type, for a start.
Actually, your recipe didn't work for me when I tried it earlier. I'm quite prepared to believe that this was due to an error on my part.
But I'll repeat that in my view Fedora is not thinking about the user in the way it used to (and the way Ubuntu is doing more than it used to, whence perhaps the fact that Ubuntu has overtaken Fedora in popularity). It doesn't matter if Fedora is 10 times as fast, if people coming to it can't work out how to use it.
This has nothing to with being "cutting edge"; it's just a matter of giving due weight to the user interface.
2012/3/22, Timothy Murphy gayleard@alice.it:
Dr. Michael J. Chudobiak wrote:
openvpn has special issues with systemd, but once you know the magic recipe, it works fine. See: https://bugzilla.redhat.com/show_bug.cgi?id=744244
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service \ /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
Can you really claim that that is as easy as "chkconfig openvpn on"? It takes 10 times as long to type, for a start.
But why are you typing such things in the first place? As far as I'm concerned, "chkconfig openvpn on" is already too long to type more than once. You can make use a script, or the command line history.
Andras
On 03/22/2012 01:04 PM, Timothy Murphy wrote:
I'd agree that the systemctl syntax is clumsier.
The CLI syntax is different, but the difference is negligible once you are used to it.
However, the *.service file syntax is much, MUCH simpler than the old init scripts!
An old-style postgrey init script: http://lists.puremagic.com/pipermail/greylist-users/2006-May/001208.html
A new-style postgrey service file: http://bugzilla.redhat.com/show_bug.cgi?id=714430#c10
There is way less wonky bash scripting in the new service file, because it is mostly declarations, rather than code. As an added bonus, the old postgrey init script never worked properly for me (it did not kill cleanly, no idea why), but the new systemd service file works great.
For example, if you declare the name of the pid file in the service file, systemd automatically knows to use that pid when stopping the service. It's brilliant.
- Mike
On 03/23/2012 01:26 AM, Dr. Michael J. Chudobiak wrote:
There is way less wonky bash scripting in the new service file, because it is mostly declarations, rather than code. As an added bonus, the old postgrey init script never worked properly for me (it did not kill cleanly, no idea why), but the new systemd service file works great.
Wish I could say the same. When systemd works - it works fine. The trouble is when it doesn't work - it just sucks for diagnosing what's going on. It's practically impossible to tell why something isn't working because you have no idea of the dependencies between services and when and how they get started. There is a lot of documentation but its very obtuse. I've seen services fail to start on boot but if you manually start them - they work. I've seen services fail to stop causing the system to hang (until you repeatedly press ctrl-alt-del) and so on. Never mind the weirdness like trying to stop a non existant service - the service shows up as failed with a systemctl -a. Can't see what use that is. I hate having to write .service on the end of everything - it's completely superfluous. I love the concept of systemctl but its human interface is just awful.
On 3/22/2012 1:04 PM, Timothy Murphy wrote:
But to return to boot-speed, how could using systemctl be any faster than an exactly equivalent command expressed in chkconfig terms?
from here: http://fedoraproject.org/wiki/Systemd "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. For more information, watch the video at http://linuxconfau.blip.tv/file/4696791/ or http://www.youtube.com/watch?v=TyMLi8QF6sw"
in other words, in can start services up in parallel, instead of waiting for each one to initiate before going to the next...
Am 22.03.2012 18:37, schrieb Claude Jones:
in other words, in can start services up in parallel, instead of waiting for each one to initiate before going to the next...
what can have the opposite effect if the disk is slow and services are producing much disc activity at start
on most machines it will improve boot performance, but not on all also the parallel start brings a lot of other troubles if a bundle of services depends on each other started in the right order and full working and systemd introduces RANDOm here because it will not start services each time in the exactly same order
however, if fedora would have done the systemd transition much cleaner most troubles would have been much less, but i doubt it will take years with the current policies to get rid of this damned sysv-scipts which are still present
Claude Jones wrote:
But to return to boot-speed, how could using systemctl be any faster than an exactly equivalent command expressed in chkconfig terms?
in other words, in can start services up in parallel, instead of waiting for each one to initiate before going to the next...
You misunderstood me. If there has been this improvement - and I've seen a slight, not dramatic, improvement - it could perfecly well have been taken up by chkconfig, which as far as I can see just draws up (or drew up) a list of daemons to start at boot-time. How they were started does not seem to have much to do with chkconfig.
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
On 03/22/2012 01:26 PM, Timothy Murphy wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl start openvpn.service
will start it running and
systemctl enable openvpn.service
will make it start @boot. HTH, HAND.
Joe Zeff wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl start openvpn.service
will start it running and
systemctl enable openvpn.service
will make it start @boot. HTH, HAND.
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
On 03/23/2012 05:26 PM, Timothy Murphy wrote:
Joe Zeff wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl start openvpn.service
will start it running and
systemctl enable openvpn.service
will make it start @boot. HTH, HAND.
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
Kind of silly.... But I always check /lib/systemd/system to make sure the name of the service is what I think it is....
[root@meimei system]# systemctl is-enabled openvpn@.service disabled
So, it seems it is named "close" to what one would expect. :-)
Am 23.03.2012 10:26, schrieb Timothy Murphy:
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
why the hell do you not read answers?
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
yes, the new openvpn service is not as simple as other ones but how did you start openvpn as client AND server on the same machine before systemd????????
if you do not like this syntax take 15 seconds and write your own servcie file as i did long ago
how would you have done THAt with the sysvinit? __________________________________
[root@srv-rhsoft:~]$ cat /etc/systemd/system/openvpn.service [Unit] Description=OpenVPN After=syslog.target network.target
[Service] Type=forking PIDFile=/var/run/openvpn/openvpn.pid ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/openvpn.pid --cd /etc/openvpn/ --config openvpn.conf Restart=always RestartSec=1
[Install] WantedBy=multi-user.target
Reindl Harald wrote:
Am 23.03.2012 10:26, schrieb Timothy Murphy:
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
why the hell do you not read answers?
Please read more carefully the posting you are responding to. I had been advised that the commands I used would start and enable openvpn. I was simply pointing out that this is not so.
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
Again, read what I said: I don't know any SIMPLE way to enable openvpn. I do not regard what you wrote as a simple way to enable a service. Also, as I pointed out, it did not work for me, though I am quite prepared to believe this was due to a typo or other error on my part. (I would not be likely to make an error with "chkconfig openvpn on".)
Am 23.03.2012 18:36, schrieb Timothy Murphy:
Reindl Harald wrote:
Am 23.03.2012 10:26, schrieb Timothy Murphy:
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
why the hell do you not read answers?
Please read more carefully the posting you are responding to
please try to understadn what people are telling you
I had been advised that the commands I used would start and enable openvpn. I was simply pointing out that this is not so.
you were advised by people never seen openvpn and blindly thinking it acts the same way as all other services
If your openvpn config file is /etc/openvpn/client.conf, do:
ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/openvpn@client.service
systemctl daemon-reload
systemctl start openvpn@client.service
systemctl status openvpn@client.service
Again, read what I said: I don't know any SIMPLE way to enable openvpn. I do not regard what you wrote as a simple way to enable a service. Also, as I pointed out, it did not work for me, though I am quite prepared to believe this was due to a typo or other error on my part. (I would not be likely to make an error with "chkconfig openvpn on".)
the quote above is NOT from me
you simply do not recognize that this is a SPECIAL CASE because it makes sense to have it active as client in one network while another instance providing openvpn as service on the same machine
how do you do that? come on tell as the syntax to enable two openvpn instances (one server and one client) with chkconfig!
ONE LAST time i post you the systemd-unit to let openvpn behave like all the years before - only one instance possible and after create this damned file you can even do "chkconfig openvpn on" because it will be redirected to systemctl in the right order
and if you like the simple syntax you can put as many copies as you need under /etc/systemd/system/ for different instances which different parameters and use "chkconfig" for all of them
so please stop whine around because ONE SPECIFIC SPECIAL SERVICE for nearly all others you can use "chkconfig" as all the years before
[root@srv-rhsoft:~]$ cat /etc/systemd/system/openvpn.service [Unit] Description=OpenVPN After=syslog.target network.target
[Service] Type=forking PIDFile=/var/run/openvpn/openvpn.pid ExecStartPre= ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/openvpn.pid --cd /etc/openvpn/ --config openvpn.conf ExecStopPost= Restart=always RestartSec=1
[Install] WantedBy=multi-user.target
On 03/23/2012 05:26 PM, Timothy Murphy wrote:
Joe Zeff wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl start openvpn.service
will start it running and
systemctl enable openvpn.service
will make it start @boot. HTH, HAND.
[tim@blanche ~]$ sudo systemctl start openvpn.service Failed to issue method call: Unit openvpn.service failed to load: No such file or directory. See system logs and 'systemctl status openvpn.service' for details. [tim@blanche ~]$ sudo systemctl enable openvpn.service Failed to issue method call: No such file or directory
Nb I know how to start the service, but I don't know any simple way to enable it.
Also....another weird/silly thing? Seems you need to do...
systemctl enable openvpn@.service
But, then the actual service to start is...
systemctl start openvpn@multi-user.service
But, of course, having not configured it one would get....
[root@f16-1 ~]# systemctl start openvpn@multi-user.service Job failed. See system logs and 'systemctl status' for details. [root@f16-1 ~]# systemctl status openvpn@multi-user.service openvpn@multi-user.service - OpenVPN Robust And Highly Flexible Tunneling Application On multi/user Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled) Active: failed since Fri, 23 Mar 2012 17:51:33 +0800; 35s ago Process: 2509 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/openvpn@.service/multi-user
On 03/22/2012 04:41 PM, Joe Zeff wrote:
On 03/22/2012 01:26 PM, Timothy Murphy wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl enable openvpn.service
As TM has been told elsewhere in this thread, this doesn't work for openvpn, because of its need for a pointer to a specific configuration file - you have to make a manual link, or use some other odd syntax. This is definitely a weird quirk that is not handled elegantly by systemd at the current time.
For some people, that's proof (PROOF I tell you!) that systemd is horrible and the developers are evil...
- Mike
On Fri, 2012-03-23 at 08:17 -0400, Dr. Michael J. Chudobiak wrote:
On 03/22/2012 04:41 PM, Joe Zeff wrote:
On 03/22/2012 01:26 PM, Timothy Murphy wrote:
Incidentally, none of the systemctl advocates has answered my query: How do I say "chkconfig openvpn on" in systemctl-speak?
I'm not that fond of systemctl, but I can help with this:
systemctl enable openvpn.service
As TM has been told elsewhere in this thread, this doesn't work for openvpn, because of its need for a pointer to a specific configuration file - you have to make a manual link, or use some other odd syntax. This is definitely a weird quirk that is not handled elegantly by systemd at the current time.
For some people, that's proof (PROOF I tell you!) that systemd is horrible and the developers are evil...
---- sounds like something that should be handled in /etc/sysconfig rather than within the systemd files themselves.
Craig
On 03/23/2012 08:32 AM, Craig White wrote:
As TM has been told elsewhere in this thread, this doesn't work for openvpn, because of its need for a pointer to a specific configuration file - you have to make a manual link, or use some other odd syntax. This is definitely a weird quirk that is not handled elegantly by systemd at the current time.
sounds like something that should be handled in /etc/sysconfig rather than within the systemd files themselves.
Yes, or provide separate openvpn-server.service and openvpn-client.service files, which read /etc/openvpn/server.conf and /etc/openvpn/client.conf respectively.
I imagine it will get sorted out one way or another... at the moment, it is a bleeding-edge corner-case oddity.
- Mike
Am 23.03.2012 13:58, schrieb Dr. Michael J. Chudobiak:
On 03/23/2012 08:32 AM, Craig White wrote:
As TM has been told elsewhere in this thread, this doesn't work for openvpn, because of its need for a pointer to a specific configuration file - you have to make a manual link, or use some other odd syntax. This is definitely a weird quirk that is not handled elegantly by systemd at the current time.
sounds like something that should be handled in /etc/sysconfig rather than within the systemd files themselves.
Yes, or provide separate openvpn-server.service and openvpn-client.service files, which read /etc/openvpn/server.conf and /etc/openvpn/client.conf respectively.
I imagine it will get sorted out one way or another... at the moment, it is a bleeding-edge corner-case oddity
i really really do not understand the problem creating a service file unter /etc/systemd/ - openvpn is a special case at all and the systemd-unit dervied from the @service si written in two minutes
[root@srv-rhsoft:~]$ cp /etc/systemd/system/openvpn.service /etc/systemd/system/openvpn2.service
[root@srv-rhsoft:~]$ nano /etc/systemd/system/openvpn2.service
[root@srv-rhsoft:~]$ systemctl enable openvpn2.service ln -s '/etc/systemd/system/openvpn2.service' '/etc/systemd/system/multi-user.target.wants/openvpn2.service'
[root@srv-rhsoft:~]$ systemctl status openvpn2.service openvpn2.service - OpenVPN Loaded: loaded (/etc/systemd/system/openvpn2.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/openvpn2.service
[root@srv-rhsoft:~]$ cat /etc/systemd/system/openvpn2.service [Unit] Description=OpenVPN After=syslog.target network.target [Service] Type=forking PIDFile=/var/run/openvpn/openvpn2.pid ExecStartPre= ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/openvpn2.pid --cd /etc/openvpn/ --config openvpn2.conf ExecStopPost= Restart=always RestartSec=1 [Install] WantedBy=multi-user.target
[root@srv-rhsoft:~]$ cat /etc/systemd/system/openvpn.service [Unit] Description=OpenVPN After=syslog.target network.target [Service] Type=forking PIDFile=/var/run/openvpn/openvpn.pid ExecStartPre= ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/openvpn.pid --cd /etc/openvpn/ --config openvpn.conf ExecStopPost= Restart=always RestartSec=1 [Install] WantedBy=multi-user.target
[root@srv-rhsoft:~]$ systemctl disable openvpn2.service rm '/etc/systemd/system/multi-user.target.wants/openvpn2.service'
[root@srv-rhsoft:~]$ rm -f /etc/systemd/system/openvpn2.service
How they were started does not seem to have much to do with chkconfig.
The init system used a series of hard-coded numbers in the init scripts to judge which services were to be started in which sequence, which was a horrible mess.
You had to make sure the service X's priority of 37 was in between service Y'x priority of 18 and service Z's priority of 56.
With systemd, you just say things like:
After=syslog.target network.target auditd.service and/or Before=poweroff.service reboot.service halt.service
Which is MUCH more concise and easy to understand. The computer figures it all out, instead of the user having to juggle priority levels.
Also, all init scripts with priorities > 37 would all have to wait for the "service X" to finish. This is not so with systemd. The service files specify the minimum dependencies. If service Z does not require service X, it can go ahead, even if service X gets delayed.
See?
- Mike
On Fri, 2012-03-23 at 08:25 -0400, Dr. Michael J. Chudobiak wrote:
The init system used a series of hard-coded numbers in the init scripts to judge which services were to be started in which sequence, which was a horrible mess.
Yet, worked well.
You had to make sure the service X's priority of 37 was in between service Y'x priority of 18 and service Z's priority of 56.
Often, I'd configured systems where I had to specifically arrange the order of a series of services so that one started after another, in a precise manner. Else, all but the first one would fail to start, and never recover.
With systemd, you just say things like:
After=syslog.target network.target auditd.service and/or Before=poweroff.service reboot.service halt.service
Which is MUCH more concise and easy to understand.
But much less precise. It's all very well to say "this," "that," and "the other," need to start after "this thing," is easier to set. But if you definitely need "this thing," followed by, "this," followed by "that," followed by "the other," in that precise order. Then the numbered scheme does exactly what you want.
For a more specific example some users may require services to start up in the following order, exactly:
network (because just about everything else requires it) ntp (because you need precise logging of everything that starts) samba (because it doesn't work if the network starts after it) apache (because it doesn't work if started before the network, and you need samba running before it for some of the files)
And the list could go on. As one thing depends on the prior thing, in a a dependent chain. Trying to get half a dozen things to fire up at once doesn't really work, as some things can't start without a previous thing. They don't begin starting up and keep on trying to start while waiting for what they depend on. They start up, once, and succeed or fail.
Sure, having to rename files by hand, to change numbers, can be a pain. But it's not beyond the potential of having a drag-and-drop interface to sort services into the required start up order.
The computer figures it all out, instead of the user having to juggle priority levels.
Evidence seems to suggest (with some prior emails about some services starting too soon) that the computer doesn't "figure it out."
It's, also, a bit of a fallacy that sequentially reading files from the hard drive to start up in the sequence that they're needed will be slower than trying to access many different files at the same time. It's like trying to read fragmented files, with more seeking than reading. And seeking is slower than reading consecutive blocks.
Trying to read the log is a major pain, too, with multiple concurrent services all splattered in together.
Am 23.03.2012 14:49, schrieb Tim:
But much less precise. It's all very well to say "this," "that," and "the other," need to start after "this thing," is easier to set. But if you definitely need "this thing," followed by, "this," followed by "that," followed by "the other," in that precise order. Then the numbered scheme does exactly what you want.
this is not true
* you can dervice your own unit-files in /etc/systemd/system/ * you can place here as much Before/After you need for a exact order * you define Requires= to make sure B,C, AND D does not get started if A fails
you can even define a main-service with as many ExecStartPre/ExecStartPost/ExecStopPre/ExecStopPost you need without touch the services itself
below my netatalk for now if the cnid-service fails ExecStart will never be called
the only problem with systemd in Fedora is that it was not ready for F15 - see changelist of httpd where start after network and named was RECENTLY added while this broke many setups where httpd is bind to specific interfaces pr rfuses to start at all because missing name resoltuion
F15 was shipped broken at all for most servcies which worked partly only by luck - this is not a design problem of systemd - this is a QA problem of fedora where nonody cares if things are done really well the last releases
[Unit] Description=Apple-Fileserver After=avahi-daemon.service [Service] Type=forking GuessMainPID=no ExecStartPre=/bin/systemctl start netatalk-cnid.service ExecStart=/usr/sbin/afpd -P /var/run/netatalk.pid -F /etc/netatalk/afpd.conf -U uams_dhx.so,uams_dhx2.so -g nobody -c 100 ExecStopPost=/bin/systemctl stop netatalk-cnid.service Restart=always RestartSec=1 [Install] WantedBy=multi-user.target
On Sat, 2012-03-24 at 00:19 +1030, Tim wrote:
But much less precise. It's all very well to say "this," "that," and "the other," need to start after "this thing," is easier to set. But if you definitely need "this thing," followed by, "this," followed by "that," followed by "the other," in that precise order. Then the numbered scheme does exactly what you want.
Tim, the point of the systemd scheme is that it allows you to specify a directed graph (actually a directed acyclic graph or DAG) of dependencies. In terms of expressive power this is a superset of what you can do with the number scheme. IOW anything you can do with the number system you can also do with a DAG, but often without overspecifying the order and hence losing potential parallelism.
I'm saying this from a theoretical standpoint. Whether the potential parallelism is really exploited and if so whether it has a real effect is another matter, as is the syntax of the systemd command set.
poc
Dr. Michael J. Chudobiak wrote:
How they were started does not seem to have much to do with chkconfig.
The init system used a series of hard-coded numbers in the init scripts to judge which services were to be started in which sequence, which was a horrible mess.
You had to make sure the service X's priority of 37 was in between service Y'x priority of 18 and service Z's priority of 56.
With systemd, you just say things like:
After=syslog.target network.target auditd.service and/or Before=poweroff.service reboot.service halt.service
Which is MUCH more concise and easy to understand. The computer figures it all out, instead of the user having to juggle priority levels.
Also, all init scripts with priorities > 37 would all have to wait for the "service X" to finish. This is not so with systemd. The service files specify the minimum dependencies. If service Z does not require service X, it can go ahead, even if service X gets delayed.
See?
- Mike
You point is from service developer. But for system administrators this nothing changes on fact that systemctl syntax is insane tedious. I must have in root .bashrc some as this helper: function a(){ [[ "$1" =~ (?|-h) ]] && { echo -e "1st param:\n -nothing-\tlist-units|grep .service\na\t\tlist-unit-files\nl\t\tlist-unit-files|grep .service 2nd param(1st=service):\n -nothing-\tstatus\ne\t\tenable\nd\t\tdisable\nr\t\trestart\ns\t\tstart\nk\t\tstop\n" return; } C="--help"; unset S if [ $# -eq 0 ]; then C="--all list-units"; S="|grep '.service'"; elif [ $# -eq 1 ]; then [ "$1" = "a" ] && C="list-unit-files"; [ "$1" = "l" ] && { C="list-unit-files"; S="|grep '.service'"; } else C="status"; S="$1"; [[ "$1" =~ . ]] || S="$S.service"; [[ "$2" =~ ^e ]] && C="enable"; [[ "$2" =~ ^d ]] && C="disable"; [[ "$2" =~ ^r ]] && C="restart"; [[ "$2" =~ ^s ]] && C="start"; [[ "$2" =~ ^k ]] && C="stop"; fi eval systemctl $C $S }
On Thu, Mar 22, 2012 at 10:04 AM, Timothy Murphy gayleard@alice.it wrote:
Chris Rouch wrote:
I'd agree that the systemctl syntax is clumsier. But on my machines, the boot time has reduced dramatically.
I agree that boot time seems to have been reduced, at a guess about 15% in my case. However, I hardly ever re-boot, so any saving there was outweighed many times by the fact that I had to read what seemed like a very long tome to discover how to start openvpn. I still haven't discovered the equivalent of "chkconfig openvpn on" under the new dispensation.
Unfortunately you have identified a *bug* in systemctl, wherein `systemctl enable` doesn't work with '@'-type services. There's no reason why it shouldn't work, so I've filed it in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=806488
In the meantime, you can work around this bug by manually creating the symlink `systemctl enable` usually creates. So, if you have a configuration file '/etc/openvpn/client.conf' and usually start the service with `systemctl start openvpn@client.service`, you would run `ln -sf /lib/systemd/system/openvpn@.service /etc/systemd/multi-user.target.wants/openvpn@client.service` to manually enable it.
-T.C.
On Thu, 2012-03-22 at 16:42 +0100, Chris Rouch wrote:
For grub2, one of the things I like is that it picked up the windows installation on the other disk, without any configuration on my part. It also picks up other linux installations on a multi-boot machine
This must be my day to be contrary. On my systems grub has always picked up the windows installation without any special configuration.
On 03/22/2012 11:56 AM, Timothy Murphy wrote:
I'd take grub2 and systemctl as two examples. In each case I've read the documentation and understand the motivation behind these developments. But I remain unconvinced that the gains outweigh the disadvantages of methods that are much harder to configure and use.
I was perfectly happy with GRUB, but systemctl is so much faster that I'm prepared to put up with the learning curve. It's a pain, but learning it is once whereas the benefit is forever.
Andrew.
On Thu, 2012-03-22 at 12:56 +0100, Timothy Murphy wrote:
I wonder if I am alone in finding some of the developments in Fedora-16 actually make life harder for the user?
I'd take grub2 and systemctl as two examples. In each case I've read the documentation and understand the motivation behind these developments. But I remain unconvinced that the gains outweigh the disadvantages of methods that are much harder to configure and use.
I don't think this is just a matter of unfamiliarity. I think one can say objectively that the new methods are more complicated than those they replace.
As a crude measure of complication the new commands take longer to type than the old, eg "systemctl start openvpn@client.service" compared with "start service openvpn".
And the output of the new commands seems much more verbose than the old: eg compare the output of "systemctl -a" or "systemctl list-units" with that of "chkconfig --list".
Could anyone bringing in these changes have honestly answered "Yes" if asked whether the new method would simplify life for the user?
---- you're being argumentative here.
The move to grub2 & systemd/systemctl really has nothing to do with the user command line interface which you should already understand since you said you understand the motivations.
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
If your beef is about specific daemons (ie openvpn), you should be submitting bugzilla entries against the package.
Craig
On Thu, 22 Mar 2012 19:36:24 -0700 Craig White craigwhite@azapple.com wrote:
The move to grub2 & systemd/systemctl really has nothing to do with the user command line interface which you should already understand since you said you understand the motivations.
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
Is this actually true? From my post reproduced below, responded to very helpfully by Ed Greshko: note the mention that the option of starting a service at boot seems to have gone...is this a bug?
Ranjan
Subject: Re: how to automatically start sshd in F16
On 03/13/2012 12:21 PM, Ranjan Maitra wrote:
Dear friends,
I was wondering how to set up on a new F16 installation so that sshd would automatically start at boot? Previously, all I had to do was to go into system-config-services and check sshd so that it would be started at boot. That option seems to have gone. I can check on the option to start it, but it does not start at boot. How do I do this?
Many thanks and best wishes, Ranjan
http://fedoraproject.org/wiki/Systemd#How_do_I_start.2Fstop_or_enable.2Fdisa...
sshd.service is the service you're asking about....
Am 23.03.2012 03:36, schrieb Craig White:
The move to grub2 & systemd/systemctl really has nothing to do with the user command line interface which you should already understand since you said you understand the motivations.
right - and that is why hey need not to be hanged in the first front or should as much compatible as possible if someone does a drop-in-replacement
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
and that is why "we" spit advanced users in the face?
"systemctl restart httpd.service" is a joke compared with "service httpd restart" - a msart developer would have made .service as default-fallback and only "httpd.socket" as example would need full qualified input
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/23/2012 07:38 AM, Reindl Harald wrote:
"systemctl restart httpd.service" is a joke compared with "service httpd restart" - a msart developer would have made .service as default-fallback and only "httpd.socket" as example would need full qualified input
That would be optimisation. A very smart programmer once taught us that "premature optimisation is the root of all evil". Perhaps the author felt that other work was of higher priority at the time?
Besides, I would expect any Linux admin worth paying who found this syntax so troublesome to be able to create a wrapper to suit their preferred invocation style with minimal effort.
alias oldservice () { systemctl $2 $1.service; }
That took about as long to think up as it did to type. I am sure you could improve upon it with little work.
# oldservice httpd status httpd.service - LSB: start and stop Apache HTTP Server Loaded: loaded (/etc/rc.d/init.d/httpd) Active: inactive (dead) CGroup: name=systemd:/system/httpd.service
# oldservice httpd start #
I'm also sure that upstream would be happy to review patches to improve usability and merge them if appropriate.
Regards, Bryn.
Am 23.03.2012 11:52, schrieb Bryn M. Reeves:
On 03/23/2012 07:38 AM, Reindl Harald wrote:
"systemctl restart httpd.service" is a joke compared with "service httpd restart" - a msart developer would have made .service as default-fallback and only "httpd.socket" as example would need full qualified input
That would be optimisation
and as i do this before i tell other people software i developed is ready i demand this sort of optimiziation
especially as i do not enforce people to use my software systemd-developers did with F15 and no, please do not come with "use another distribution" or any such laughable phrase
A very smart programmer once taught us that "premature optimisation is the root of all evil".
that may be correct in many cases
in the case "systemctl restart/stop/start is mostly used for services" it is a silly argument for ".service has to be typed all the time"
Perhaps the author felt that other work was of higher priority at the time?
perhaps the author sould have finished his software before F15 or deleayed it for F16 at all
with F16 systemd feels usebale the version in F15 was poor crap from the user point of view
Besides, I would expect any Linux admin worth paying who found this syntax so troublesome to be able to create a wrapper to suit their preferred invocation style with minimal effort.
alias oldservice () { systemctl $2 $1.service; }
i guess few people are using more aliases and scripts as i do for years now - but it is poor software-design need to do this every where because banana-software is called "release"
--- On Fri, 2012/3/23, Bryn M. Reeves bmr@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/23/2012 07:38 AM, Reindl Harald wrote:
"systemctl restart httpd.service" is a joke compared with "service httpd restart" - a msart developer would have made .service as default-fallback and only "httpd.socket" as example would need full qualified input
That would be optimisation. A very smart programmer once taught us that "premature optimisation is the root of all evil". Perhaps the author felt that other work was of higher priority at the time?
That is not optimization, that is interface design. The two are entirely different. The "premature optimization" bit is about choosing implementation clarity (expression) at the expense of execution speed over potentially confusing code that increases performance at runtime (optimization).
The difference between .service being a permitted implication VS a mandatory explication is one of interface and does not impact the implementation of the subsystem. Its the same argument as requiring that everyone actually type "self" in 'def foo(self):' in Python. I think its silly, others think it is more clear to be explicit to that degree when programming.
But pushing systemd around from the command line is not programming unless its part of a script, and then the explicit .service extension is entirely appropriate. And speaking of scripting the shell, we've had this debate before a very long time ago. It resulted in the tradition of providing GNU flag extensions in addition to the old-style terse single-dash switches for the vast majority of command line tools. In scripts it can be polite (well, used to be considered polite, if anyone would remember today...) to write 'cut --delimiter="-" --fields=2,3 foo.txt' instead of 'cut -d "-" -f 2,3', but both are perfectly acceptable and this provides a way to be explicit for posterity yet terse for practical reasons.
I'm sure more people around here than me spent their early years watching the flame wars of the late 80's and early 90's unfold over all this stuff (or in the case of JZ he was probably directly involved instead of being a youngster on the sidelines). Anyway, I think we should learn from those discussions and how the command line evolved instead of trying to reinvent things that are difficult (but that does not mean the status quo rules the day in the face of clearly better alternatives).
Have we forgotten that CLI *is* an interface and hence worth discussing? The "I" is there for a reason. And how on earth is it possible that we've forgotten what a cultural rule-of-thumb as important as "premature optimization is the root of all evil" actually means?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/27/2012 12:12 PM, 夜神 岩男 wrote:
That is not optimization, that is interface design. The two are entirely different. The "premature optimization" bit is about choosing implementation clarity (expression) at the expense of execution speed over potentially confusing code that increases performance at runtime (optimization).
The set of verbs and options systemctl accepts are the interface design. I think you are stretching things beyond the plausible to try to claim that a minor tweak to save 8 characters in a common invocation is UI design. It's just optimizing a common case.
The difference between .service being a permitted implication VS a mandatory explication is one of interface and does not impact the implementation of the subsystem. Its the same argument as requiring that everyone actually type "self" in 'def foo(self):' in Python. I think its silly, others think it is more clear to be explicit to that degree when programming.
But pushing systemd around from the command line is not programming unless its part of a script, and then the explicit .service extension is entirely appropriate. And speaking of scripting the shell, we've had this debate before a very long time ago. It resulted in the tradition of providing GNU flag extensions in addition to the old-style terse single-dash switches for the vast majority of command line tools. In scripts it can be polite (well, used to be considered polite, if anyone would remember today...) to write 'cut --delimiter="-" --fields=2,3 foo.txt' instead of 'cut -d "-" -f 2,3', but both are perfectly acceptable and this provides a way to be explicit for posterity yet terse for practical reasons.
No idea what point any of this is getting at. The systemd utilities support both long and short options where it makes sense to do so. It's almost as though someone designed it that way..
Have we forgotten that CLI *is* an interface and hence worth discussing? The "I" is there for a reason. And how on earth is it possible that we've forgotten what a cultural rule-of-thumb as important as "premature optimization is the root of all evil" actually means?
Go ahead and discuss to your heart's content but flaming at people and calling a UI "unusable" and implying that the authors of that interface are "not smart" has no place in that discussion and should not be accepted.
Regards, Bryn.
Craig White wrote:
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
That sounds absurd to me. Maybe I'm not a "typical user" (who is?) but I often need to start or restart services, eg yesterday I had to restart sendmail after changing my SMARTHOST. I also restarted dhcpd after adding another device to dhcpd.conf . Are you suggesting I should re-boot after each of these?
I remember that NetworkManager used to have the mantra "It just works". They seem to have dropped it now NM actually does work most of the time.
On Fri, 2012-03-23 at 10:39 +0100, Timothy Murphy wrote:
Craig White wrote:
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
That sounds absurd to me. Maybe I'm not a "typical user" (who is?) but I often need to start or restart services, eg yesterday I had to restart sendmail after changing my SMARTHOST. I also restarted dhcpd after adding another device to dhcpd.conf . Are you suggesting I should re-boot after each of these?
---- no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui. ----
I remember that NetworkManager used to have the mantra "It just works". They seem to have dropped it now NM actually does work most of the time.
---- and I think you have nailed one of the primary purposes of Fedora... that to offer the leading edge of software releases puts the developed code in front of significant numbers of users for wider testing, bug reports, patches. The concept of release early and often at work. Releasing early means that not everything initially works as intended.
Craig
On 23/03/12 17:37, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
s-c-s is DE agnostic, running fine on Xfce.
Am 23.03.2012 18:42, schrieb Frank Murphy:
On 23/03/12 17:37, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
s-c-s is DE agnostic, running fine on Xfce
most machines where systemctl is relevant do not evem have any DE so what.....
what all the people crying here missing in systemctl start/stop is that they can use their holy chkconfig and it will be redirected
the guy whining about openvpn does simply not recognize that this is a SPECIAL CASE because it makes sense to have it active as client in one network while another instance providing openvpn as service on the same machine
[root@srv-rhsoft:~]$ chkconfig httpd off Hinweis: Anfrage wird weitergeleitet an »systemctl disable httpd.service«. rm '/etc/systemd/system/multi-user.target.wants/httpd.service'
[root@srv-rhsoft:~]$ chkconfig httpd on Hinweis: Anfrage wird weitergeleitet an »systemctl enable httpd.service«. ln -s '/lib/systemd/system/httpd.service' '/etc/systemd/system/multi-user.target.wants/httpd.service'
Reindl Harald wrote:
most machines where systemctl is relevant do not evem have any DE so what.....
Presumably you are talking about Fedora, since you are contributing to a Fedora newsgroup. I would have thought an overwhelming majority of Fedora users are running services, and also have a DE.
the guy whining about openvpn does simply not recognize that this is a SPECIAL CASE because it makes sense to have it active as client in one network while another instance providing openvpn as service on the same machine
First of all, I imagine there are very few people running an openvpn server and an openvpn client on the same Fedora machine.
Secondly, there are many services where one could in theory be running two instances on the same machine.
Am 23.03.2012 21:49, schrieb Timothy Murphy:
Reindl Harald wrote:
most machines where systemctl is relevant do not evem have any DE so what.....
Presumably you are talking about Fedora, since you are contributing to a Fedora newsgroup. I would have thought an overwhelming majority of Fedora users are running services, and also have a DE.
hm - only i maintain currently 25 fedora isntances not having any DUI
the guy whining about openvpn does simply not recognize that this is a SPECIAL CASE because it makes sense to have it active as client in one network while another instance providing openvpn as service on the same machine
First of all, I imagine there are very few people running an openvpn server and an openvpn client on the same Fedora machine.
first of all there are very few people running openvpn as service at all, they majority running vpn-services as client are the one with a DE
Secondly, there are many services where one could in theory be running two instances on the same machine
not so much and they one who makes sense are not much better useable - setup a second mysqld instance with a systemd-unit takes 2 minutes (proven by done multiple times)
On Fri, 2012-03-23 at 10:37 -0700, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
---- No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
Craig
On Sat, 24 Mar 2012 06:18:45 -0700 Craig White craigwhite@azapple.com wrote:
On Fri, 2012-03-23 at 10:37 -0700, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
Actually, as I mentioned a couple of days ago, there is now no option to start the job upon reboot in system-config-services. It had to be started at every reboot unless the systemd command was given to enable it at boot. I brought this up with respect to the sshd daemon.
I had this issue on a LXDE spin. Is this a bug?
Ranjan
On Sat, 2012-03-24 at 08:24 -0500, Ranjan Maitra wrote:
On Sat, 24 Mar 2012 06:18:45 -0700 Craig White craigwhite@azapple.com wrote:
On Fri, 2012-03-23 at 10:37 -0700, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
Actually, as I mentioned a couple of days ago, there is now no option to start the job upon reboot in system-config-services. It had to be started at every reboot unless the systemd command was given to enable it at boot. I brought this up with respect to the sshd daemon.
I had this issue on a LXDE spin. Is this a bug?
---- appears that enable/disable options aren't functional, only start/stop/restart and that would be a bug.
Craig
On Sat, 24 Mar 2012 06:43:11 -0700 Craig White craigwhite@azapple.com wrote:
On Sat, 2012-03-24 at 08:24 -0500, Ranjan Maitra wrote:
On Sat, 24 Mar 2012 06:18:45 -0700 Craig White craigwhite@azapple.com wrote:
On Fri, 2012-03-23 at 10:37 -0700, Joe Zeff wrote:
On 03/23/2012 05:27 AM, Craig White wrote:
no - if command line syntax/invocations are challenging, you can do this rather simply via the 'system-config-services' gui.
Assuming, of course, that your DE has something like that. Not all Fedora users run Gnome, you know.
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
Actually, as I mentioned a couple of days ago, there is now no option to start the job upon reboot in system-config-services. It had to be started at every reboot unless the systemd command was given to enable it at boot. I brought this up with respect to the sshd daemon.
I had this issue on a LXDE spin. Is this a bug?
appears that enable/disable options aren't functional, only start/stop/restart and that would be a bug.
Correct. So, then this should be filed as a bug? Or a feature?
In any case, it appears that the advice to use the system-config-services gui is no longer ready for implementation.
My personal view wrt this and similar discussions: the biggest USP of linux and unix-based systems is stability: it would be nice not to compromise on that. Despite its leading edge status, Fedora did maintain that from 1 through the initial days of 14 (even though there were hiccups in 2 with jump from 2.4 to 2.6). I hope whatever changes are introduced do not cause people like me to wonder about this.
Many thanks and best wishes, Ranjan
On 03/24/2012 06:18 AM, Craig White wrote:
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
My finding it on either of my machines would prove nothing as I migrated both of them from Gnome to XFCE and still have various Gnome stuph on them.
Am 24.03.2012 19:30, schrieb Joe Zeff:
On 03/24/2012 06:18 AM, Craig White wrote:
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
My finding it on either of my machines would prove nothing as I migrated both of them from Gnome to XFCE and still have various Gnome stuph on them.
how does this matter?
if you do "yum install systemconfig-*" it is installed finished, that was it
it does not matter which package is default for which DE with your argumentation every package not in the default-install would be not useable for anything because "it is not there possibly at KDE"
Am 24.03.2012 19:49, schrieb Joe Zeff:
On 03/24/2012 11:38 AM, Reindl Harald wrote:
how does this matter?
It means that if I already have the program I have no way of knowing if it's DE agnostic, or simply left over from when I used Gnome
what is "DE agnostic"? you will not believe it but you can even make "yum install gftp gedit" on KDE systems, really that works, proven
your "Assuming, of course, that your DE has something like that" in context of "system-config-*" is simply a useless comment, accept it and learn to understand that fedora apckages are NOT "DE agnostic" at all
On 03/24/2012 11:53 AM, Reindl Harald wrote:
what is "DE agnostic"? you will not believe it but you can even make "yum install gftp gedit" on KDE systems
Yes, by bringing in whatever Gnome packages it needs. "DE agnostic" doesn't care what the DE is because it doesn't need any support packages from one or another DE.
On Sat, 24 Mar 2012, Reindl Harald wrote:
Am 24.03.2012 19:49, schrieb Joe Zeff:
On 03/24/2012 11:38 AM, Reindl Harald wrote:
how does this matter?
It means that if I already have the program I have no way of knowing if it's DE agnostic, or simply left over from when I used Gnome
what is "DE agnostic"? you will not believe it but you can even make "yum install gftp gedit" on KDE systems, really that works, proven
I'm feeling grumpy, so I'll point out that DE-agnostic is a misnomer. As a rule, someone who says whatever-agnostic means whatever-apathetic.
Am 25.03.2012 04:00, schrieb Joe Zeff:
On 03/24/2012 06:40 PM, Michael Hennebry wrote:
As a rule, someone who says whatever-agnostic means whatever-apathetic.
Possibly referring to it as "DE indifferent" would be best.
why do you not realize that all your stiff is off-topic? the answer to a question was "system-config-services" NOBODY except you brouth DE's in the game why? because this doe snot matter if someone needs program X yum will pull the deps that is why package managment exists
Reindl Harald wrote:
the answer to a question was "system-config-services"
I must confess that I was not aware of this program. In general I've found system-config-* programs - in particular system-config-printer and system-config-network - are more likely to cause problems than solve them.
In any case, thank you for pointing out this program (though you could have done it more courteously).
However, I just tried the program on my Fedora-16/KDE laptop, and it seems to be less than the complete answer. Enable, Disable and Start are greyed out on my system, and there does not appear to be a Status tab.
On 25/03/12 10:05, Timothy Murphy wrote:
Reindl Harald wrote:
However, I just tried the program on my Fedora-16/KDE laptop, and it seems to be less than the complete answer. Enable, Disable and Start are greyed out on my system, and there does not appear to be a Status tab.
Not fully finalised but try: yum install systemd-gtk
It's a gui to the whole systemd thing. Still a wip. YMMV
Frank Murphy wrote:
Not fully finalised but try: yum install systemd-gtk It's a gui to the whole systemd thing.
I yum-installed this, but couldn't see how to run it. (It didn't appear to make any difference to system-config-services.)
On Sun, Mar 25, 2012 at 14:11, Timothy Murphy gayleard@alice.it wrote:
Not fully finalised but try: yum install systemd-gtk It's a gui to the whole systemd thing.
I yum-installed this, but couldn't see how to run it. (It didn't appear to make any difference to system-config-services.)
$ systemadm
Am 25.03.2012 11:05, schrieb Timothy Murphy:
Reindl Harald wrote:
the answer to a question was "system-config-services"
I must confess that I was not aware of this program. In general I've found system-config-* programs - in particular system-config-printer and system-config-network - are more likely to cause problems than solve them.
i was not the one who recommended it because i never use any GUI crap since i can type commands and make symlinks
In any case, thank you for pointing out this program (though you could have done it more courteously).
as said i pointed not out the program, i was only angry that Joe Zeff does not shut up with his "Not all Fedora users run Gnome" to prove again his absent knowledge of anything
However, I just tried the program on my Fedora-16/KDE laptop, and it seems to be less than the complete answer. Enable, Disable and Start are greyed out on my system, and there does not appear to be a Status tab.
as said: i do not use the graphical crap
use "systemctl enable/disable/start/stop" and since it's otput are the symlinks it creates and removes it should be very easy to learn how to act with specia services like openvpn or by "cat something.service" even to learn in 30 seconds how to write your own simple unit-file
On 03/25/2012 02:48 AM, Reindl Harald wrote:
as said i pointed not out the program, i was only angry that Joe Zeff does not shut up with his "Not all Fedora users run Gnome" to prove again his absent knowledge of anything
Although you are a very knowledgeable person, you're also an arrogant, narrow-minded, intolerant horses ass who can't understand that not everybody does things your way. Grow up and stop acting like a child.
On Sat, 2012-03-24 at 11:30 -0700, Joe Zeff wrote:
On 03/24/2012 06:18 AM, Craig White wrote:
No - but I was assuming that a Fedora user would at least at least have enough sense to try running system-config-services before jumping to any conclusions and thus find out that it is an executable that will run irrespective of the DE.
My finding it on either of my machines would prove nothing as I migrated both of them from Gnome to XFCE and still have various Gnome stuph on them.
---- regardless of whatever DE you choose, packages run because the necessary libs are installed. That is why I can use evolution with KDE (Evolution is a Gnome program through and through). Likewise, Firefox depends upon Gnome libs and you couldn't run FF on Linux without them.
Migrated or fresh install, the full 'GNOME Desktop Environment' group package set installed or not isn't material to whether system-config-services gets installed or whether it works.
I don't understand why you sought to insert yourself into this thread since you only created a tangential thread which focuses on your lack of knowledge and intellectual curiosity.
Craig
On 03/24/2012 06:27 PM, Craig White wrote:
regardless of whatever DE you choose, packages run because the necessary libs are installed.
Yes. I know. I also know that I can install Gnome-centric programs without pulling in other parts of Gnome because they're already installed. Thus, it's hard for me to tell if a package is part of Gnome or not.
The goal is that the typical user would never actually interact with grub (grub2) or systemctl from the command line at all. Grub manipulations occurring when kernels are installed or removed, systemctl commands can be handled via 'system-config'services'
Thats one of the diseases Fedora seems to be suffering from. The 'Oh but it doesn't matter about the lower levels' problem. F15 and F16 screw up upgrades horribly and leave services disabled they shouldn't. Thats a fail. It also totally contradicts the defence of "oh but you never have to deal with it"
Similarly with grub2. The complete failure of the upgrade tools and installer to get the job done right combined with the half baked and over convoluted script mess makes it a nightmare for users to fix.
Low levels do matter. Being able to fix stuff does matter. Things *do* go wrong.
Alan
I'll just note that you are not alone in questioning the wisdom of the current directions. (Yeah, plural. That's part of the problem.)
Not alone in your frustrations, either.
-- Joel Rees
-
Aaron Konstam -
Alan Cox -
Andras Simon -
Andrew Haley -
Bryn M. Reeves -
Chris Rouch -
Claude Jones -
Craig White -
Dr. Michael J. Chudobiak -
Ed Greshko -
Frank Murphy -
Franta Hanzlík -
Ian Chapman -
Joe Zeff -
Joel Rees -
Michael Hennebry -
Patrick O'Callaghan -
Ranjan Maitra -
Reindl Harald -
Richard Shaw -
Suvayu Ali -
T.C. Hollingsworth -
Tim -
Timothy Murphy -
Tom Horsley -
夜神 岩男