I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users.
Yes, that's basically been (at least) ubuntu's goal ever since it was first released. And, in my eyes, that's pretty pointless an idea, because running a GUI-only Linux gives you the worst of both worlds: GUIs that look and feel somewhat "bolted on", don't integrate nice with the system (due to the fundamental mismatch of paradigms) and are prone to frequent and major hiccups ranging from "just a short lag" to crash-and-burn. While getting the shit end of the GUI landscape (both Microsoft and Apple have that part worked out *much* better), you're also missing out on the efficiency and flexibility offered by the shell and the standard toolset. So what's left? Ah right, a ton of free GUI programs a few of which even remotely usable (though generally inferior to their commercial counterparts). So, honestly, I don't get it. The use-case for GUI-only Linux, that is. To put it as a car analogy, it's as if you'd buy a shiny new car, then put in reverse and from then on completely ignore the gearbox, because reverse kind of works and it still takes you everywhere with 20 km/h. Only in the rare occasions where you accidentally break your rear window from reversing into something, you'd for a short moment shift into a forward-gear to get you out of the mess, then continue reversing.
This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
Yes, that's right.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init.
I've just sampled a few Linux machines i have access to (running debian stable and -oldstable, respectively), a quick look at/bin,/sbin,/usr/bin and/usr/sbin turned up around 300 shell scripts completely unrelated to system V init. Most of them simply don't have a.sh extension so when listing the directory they don't stand out. YMMV, would be interesting to see if that number goes down on systemd-enabled distros to see if your statement is true or not.
After all, a lot of unix tools are written in C.
Yes, but don't forget that "programs" are the building-blocks of shell scripts; it's one level of abstraction higher. The tools itself are written in C for good reasons (efficiency, mainly), the shell itself too, of course. It would be quite difficult to come up with the standard toolset completely written in shell, including the shell itself:)
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
The purpose of this server is to deal with all the desktop/office machines which run Linux. One half of the user base are (mostly surprisingly computer-illiterate) mathematicians, the other half is entirely computer-illiterate non-scientific personnel; secretarians, a janitor, etc. They're all expecting computers that work, are GUI-only driven, and, obviously, they're users, not root. Since it's quite a number of users, we discover quite a numb
1) God dammit, no. I give up trying to explain this to you since it looks like you're intentionally trying to miss the point.
2) That statement is meaningless and pulled out of your ass.
3) So there are two interfaces, one allows you to do some stuff, the other allows you to do all stuff, including fixing the first mentioned interface. BTW I'm not saying that a shell script is the primary interface, but that the shell is. The command line shell in particular. Do you understand the difference? (Rhetorical question; clearly you don't otherwise you wouldn't say something as ridiculous).
6) Yes, no shit, linux is not unix. That doesn't invalidate my point that the success came from adhering to the unix philosophy. There are already successful OSs that adhere to the opposite, so trying to turn linux into one is futile and stupid.
7) What in the actual fuck makes you believe I'd run Linux machine other than at work? I've made it clear 2 or 3 times, seeing how much you're missing or skipping here, is this language barrier?
You're not rebooting for security related fixes to the kernel or core components like libc? That figures.
8) The fact that this makes you laugh only shows that there really must be some sort of language barrier...
Okay i said i would not continue feeding you, but here's one last bite:
1) which is irrelevant to the topic because i picked the 'do it manually' example just for the purposes of illustrating how knowing the shell is useful in a generic way, while knowing systemd does not. Stop pretending that i had proposed everybody ran ifconfig to do things manually. If you really think that was the gist of my statement, then you must have missed the point (which is odd because you agreed with it that particular part later on)
I cannot really parse 2), especially the first sentence, but i agree that "normalization" (which i take for 'writing POSIX shell scripts instead of stuff riddled with bashisms') might have been a good idea, but then again, this is linux and the distro diversity is, apparently, a feature. (you can see the (rough) concept working very well on the BSDs (which don't do system V init, but rc is also script-driven (with configuration separate))).
3-5: Hilariously naive. This is all assuming that everything works, which is circular reasoning of the most ridiculous kind in a discussion directly related to the question whether things do or do not work. When something fails, you better hope that your GUI allows you to fix it, because if it doesn't, or if the GUI itself fails, you're left with the shell. I don't see how you can deny that that is the primary user interface.
6. Yeah, we call this 'integration' and 'feature creep'. It's a direct conflict with the principles that have led unix to its current success. We've seen how the integrated way turns out to work on other platforms. If you're in for a car analogy, this is like trying to tell bikers that they really ought to add another set of wheels, and replace their handlebar with a steering wheel, because it works so well with their cars.
7. the 'shitstorm' is implicit in the trouble and apparent pointlessness of 'just-because' migrating a larger set of computers to use the shiny new system. you might be used to just installing using a live cd and after that it more or less works, but in a bigger (and at my workplace that isn't even big, a mere ~200 machines) setup it's not that simple. (to get ahead of the obvious response: yes, installation, configuration etc is completely automated, the workload is not the installation itself, but ensuring "everything" the users are exposed to continues to work as expected. fixing a dozen self-maintained patches to components which have been upgraded (yes, we always submit the patches upstream, some maintainers don't care). I don't even want to imagine what would happen if the servers were linux based, too. For comparison, the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined. The former's uptime tends to be measured in days, the latters' in years...
8. I think I know better which of *my* questions are of rhetorical nature and which are actual questions, because, you know, i'm the one typing them. Or did reading comprehension get into your way again?
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
I was asking for a source on your definition, not for you repeating your belief.
2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts.
Okay, init scripts are not a central part of the sysV init system. Today i learned. (Hint: init scripts/are/ the central element, conceptually, of system V init.)
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here.
I suggest you practice reading comprehension, because you're so utterly missing the point, it's not even funny anymore. Hint: I claimed nothing about any of the straw man you're tearing down here. In particular I didn't suggest that users ought to ifconfig manually, or configure there IPs statically. If your attention span is too short to just read and follow the reasoning in order to understand what point i was trying to make, i can't help you.
sysadmin is not the dominant specie in the Linux world.
Another straw man, I didn't claim any of this. But now that you say it, yes, they actually are. People running linux at home essentially are their own sysadmins, people who run linux at work tend to rely on a sysadmin to do all the adminstrative crap for them.
The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
It being ignored by users does not mean it's not the primary user interface anymore. You simply cannot completely admin/fix your system with a shiny GUI. So strictly speaking, the shell is the *only* real user interface.
4) Systemd is really simpler to learn that shell script.
I'm starting to wonder whether you're missing the point on purpose, or whether it's actual bad reading comprehension. I'll repeat myself, once more: Learning systemd helps you at doing systemd-specific stuff. Learning shell helps you at using your OS. Those two things have a large difference in scope of applicability.
* Sysadmins are a minority of Linux users.
Yet, they are fully exposed to all the shitstorm, and their job is to shield the users from that. So quite an important minority, if at all.
* Distributions like Debian support/etc/network/interfaces with systemd.
So what?
* There are sysadmin already using systemd.
So what? There are even more sysadmins running Windows networks and big monolothic "networking appliances"
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
That's only if you're ignoring existing solutions.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
So what? Also, what does "there are still there" mean?
* Still, a lot of forum get post from 'sysadmin' complaining.
Yes. Do you really believe this would be the case if there was nothing wrong with systemd?
Note that all questions are of rhetorical nature, i'm not going to feed you any more.
We're obviously using "helper script" to refer to different things.
No, by definition helper scripts must already be part of the distribution.
I completely disagree, but I wasn't aware of that there's an accepted definition. Mind sharing the source?
[...] system V init helper scripts.
I'd hesitate to call the sysV init scripts "helper" scripts, because they are the central mechanism (apart from lil' init itself). The "central element" of systemd are the parts witten in C, of which there (apart form init itself) is no such equivalent in system V init.
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration.
No. I knew you'd bring up something like this, but, no. The manual way to configure an interface is one execution of the ifconfig(8) program (or whatever is currently hip in the linux world). This is the part that has to be "learned"; you have to remember that the program's name is ifconfig, and that it accepts an interface name, followed by an address family, followed by an address. Or else, that there's a man page. That's the "hard" part, and it's the same (modulo constant NIH-ing of the interface configuration programs due to what probably is an underlying design flaw) on both sysVinit and systemd machines
Now, system V runs that command in a shell script and that's it.
If now you feel like objecting "but it means i need to learn the shell!", then here's the important piece you're missing: If you're using a unix-like OS, and you don't know how to handle a shell, then there's your problem. It's the primary user interface. It's not only for running init scripts but provides a direct value for almost every other task imaginable.
Now, in systemd, one has to additionally learn systemd. It doesn't mean you can forget your shell. It does mean, however, that you have to invest significant time to understand and learn the huge piece of shit that is systemd. Apart from professional sysadmins, whose time would be better spent administering their systems, I don't realistically see anyone else going to do that. It's video tutorials and just-do-this-special-trick wiki articles all the way. Speaking of, is proper documentation at least theoretically available now?
Sysadmin are not the only users of Linux. Real sysadmin already known that leading distributions support the usual way of configuring a static IP address even with systemd. Proactive sysadmin already have learned systemd and are ready to manage it if it's not already the case. There is just a noise from a minority of 'sysadmin' that are neither maintainers, nor proactive, nor willing accepting that systemd will not be the end of the universe, and so frustrated that there can only wrote there distress in the forums.
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
, exactly the same amount of file on system V init.
Not quite, but whatever.
2) The/usr/local/bin/net-up.sh and/usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are/not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this... odd... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.
, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
(I mostly agree with this, but it's beside the point)
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English.
Fair enough. So a twisted parallel universe it indeed is! (just kidding)
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications
Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.
and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.
How aren't they related to systemd? I'm not following, I think.
The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
So you see how pointless it is?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug... A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for/etc/network/interfaces with systemd so basically nothing changed for the users.
Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.
Why do you put whitespace in front of question marks?
I sure did look at it (and it made me laugh *even* harder, but that's beside the point).
I'm sure willing to believe that you "know better than me" how to deploy big monolithic number crunchers "globally for a living". Unfortunately for you, this was about networking. (It's a fairly new idea, you might not have heard of it yet). So I'd suggest you familiarize yourself with the fundamentals of networking, in order to avoid making yourself look like a complete idiot next time
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I hope this one is simple enough for your use case.
No, it's not; and more to the point, I don't have a real "use case". As said:
The other day I had a spare machine sitting around [.........] [and then] I nuked [it]
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
The other day I had a spare machine sitting around, and decided to install some "modern" Linux distro, just to get some first-hand experience with systemd. I decided to install Arch.
Halfway through the installation, I arrived at the network interface configuration. I do run a dhcpd, but for this test machine, I decided to set it to a static IP address (in 192.168.1.0/24). For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):
printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0 printf 'defaultroute=(gateway addr)' >>/etc/rc.conf
I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to/etc/network/interfaces.
So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki
Persistent configuration on boot using systemd
First create a configuration file for the systemd service, replace interface with the proper network interface name:
[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.
Source Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address. At that point I nuked the machine and called myself lucky for not having to cope with this shit.
Your comment has too few characters per line (currently 24.9). Please ignore everything below;/. wouldn't let me comment without it
The log file is expected to reside in the/var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t
How did it take you that long to read the handful of comments that existed at the time?
because it couldn't make more clear how (as per/. etiquette, of course, I know) directly jumping to the comment section is your usual MO, when in reality, the occasional guy who actually does spend a few minutes on reading TFA is not unheard of. Therefore it could have been a funny and subtle troll as well; thanks for ruling out that possibility:).
Besides, It's also very possible that the poster just reads/. the way I do, which is skimming the front page for stories of potential interest (i know, i know), opening them in background tabs, and only/then/ going through the opened stories, eh, comment sections, one by one. So there's quite a delay between clicking on a story (causing comments to be loaded), and actually looking at it for the first time.
Actually with all the 3rd party javascripts on here, I'd like to correct my estimate to about 40-50 machines. Try get a basic clue on what comprises a network.
Slashdot Mirror
I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users.
Yes, that's basically been (at least) ubuntu's goal ever since it was first released. And, in my eyes, that's pretty pointless an idea, because running a GUI-only Linux gives you the worst of both worlds: GUIs that look and feel somewhat "bolted on", don't integrate nice with the system (due to the fundamental mismatch of paradigms) and are prone to frequent and major hiccups ranging from "just a short lag" to crash-and-burn. While getting the shit end of the GUI landscape (both Microsoft and Apple have that part worked out *much* better), you're also missing out on the efficiency and flexibility offered by the shell and the standard toolset. So what's left?
Ah right, a ton of free GUI programs a few of which even remotely usable (though generally inferior to their commercial counterparts). So, honestly, I don't get it. The use-case for GUI-only Linux, that is. To put it as a car analogy, it's as if you'd buy a shiny new car, then put in reverse and from then on completely ignore the gearbox, because reverse kind of works and it still takes you everywhere with 20 km/h. Only in the rare occasions where you accidentally break your rear window from reversing into something, you'd for a short moment shift into a forward-gear to get you out of the mess, then continue reversing.
This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
Yes, that's right.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init.
I've just sampled a few Linux machines i have access to (running debian stable and -oldstable, respectively), a quick look at /bin, /sbin, /usr/bin and /usr/sbin turned up around 300 shell scripts completely unrelated to system V init. Most of them simply don't have a .sh extension so when listing the directory they don't stand out. YMMV, would be interesting to see if that number goes down on systemd-enabled distros to see if your statement is true or not.
After all, a lot of unix tools are written in C.
Yes, but don't forget that "programs" are the building-blocks of shell scripts; it's one level of abstraction higher. The tools itself are written in C for good reasons (efficiency, mainly), the shell itself too, of course. It would be quite difficult to come up with the standard toolset completely written in shell, including the shell itself :)
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
The purpose of this server is to deal with all the desktop/office machines which run Linux. One half of the user base are (mostly surprisingly computer-illiterate) mathematicians, the other half is entirely computer-illiterate non-scientific personnel; secretarians, a janitor, etc. They're all expecting computers that work, are GUI-only driven, and, obviously, they're users, not root. Since it's quite a number of users, we discover quite a numb
1) God dammit, no. I give up trying to explain this to you since it looks like you're intentionally trying to miss the point.
2) That statement is meaningless and pulled out of your ass.
3) So there are two interfaces, one allows you to do some stuff, the other allows you to do all stuff, including fixing the first mentioned interface. BTW I'm not saying that a shell script is the primary interface, but that the shell is. The command line shell in particular. Do you understand the difference? (Rhetorical question; clearly you don't otherwise you wouldn't say something as ridiculous).
6) Yes, no shit, linux is not unix. That doesn't invalidate my point that the success came from adhering to the unix philosophy. There are already successful OSs that adhere to the opposite, so trying to turn linux into one is futile and stupid.
7) What in the actual fuck makes you believe I'd run Linux machine other than at work? I've made it clear 2 or 3 times, seeing how much you're missing or skipping here, is this language barrier?
You're not rebooting for security related fixes to the kernel or core components like libc? That figures.
8) The fact that this makes you laugh only shows that there really must be some sort of language barrier...
Okay i said i would not continue feeding you, but here's one last bite:
1) which is irrelevant to the topic because i picked the 'do it manually' example just for the purposes of illustrating how knowing the shell is useful in a generic way, while knowing systemd does not. Stop pretending that i had proposed everybody ran ifconfig to do things manually. If you really think that was the gist of my statement, then you must have missed the point (which is odd because you agreed with it that particular part later on)
I cannot really parse 2), especially the first sentence, but i agree that "normalization" (which i take for 'writing POSIX shell scripts instead of stuff riddled with bashisms') might have been a good idea, but then again, this is linux and the distro diversity is, apparently, a feature. (you can see the (rough) concept working very well on the BSDs (which don't do system V init, but rc is also script-driven (with configuration separate))).
3-5: Hilariously naive. This is all assuming that everything works, which is circular reasoning of the most ridiculous kind in a discussion directly related to the question whether things do or do not work. When something fails, you better hope that your GUI allows you to fix it, because if it doesn't, or if the GUI itself fails, you're left with the shell. I don't see how you can deny that that is the primary user interface.
6. Yeah, we call this 'integration' and 'feature creep'. It's a direct conflict with the principles that have led unix to its current success. We've seen how the integrated way turns out to work on other platforms. If you're in for a car analogy, this is like trying to tell bikers that they really ought to add another set of wheels, and replace their handlebar with a steering wheel, because it works so well with their cars.
7. the 'shitstorm' is implicit in the trouble and apparent pointlessness of 'just-because' migrating a larger set of computers to use the shiny new system. you might be used to just installing using a live cd and after that it more or less works, but in a bigger (and at my workplace that isn't even big, a mere ~200 machines) setup it's not that simple. (to get ahead of the obvious response: yes, installation, configuration etc is completely automated, the workload is not the installation itself, but ensuring "everything" the users are exposed to continues to work as expected. fixing a dozen self-maintained patches to components which have been upgraded (yes, we always submit the patches upstream, some maintainers don't care). I don't even want to imagine what would happen if the servers were linux based, too. For comparison, the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined. The former's uptime tends to be measured in days, the latters' in years...
8. I think I know better which of *my* questions are of rhetorical nature and which are actual questions, because, you know, i'm the one typing them. Or did reading comprehension get into your way again?
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
I was asking for a source on your definition, not for you repeating your belief.
2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts.
Okay, init scripts are not a central part of the sysV init system. Today i learned. (Hint: init scripts /are/ the central element, conceptually, of system V init.)
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here.
I suggest you practice reading comprehension, because you're so utterly missing the point, it's not even funny anymore. Hint: I claimed nothing about any of the straw man you're tearing down here. In particular I didn't suggest that users ought to ifconfig manually, or configure there IPs statically. If your attention span is too short to just read and follow the reasoning in order to understand what point i was trying to make, i can't help you.
sysadmin is not the dominant specie in the Linux world.
Another straw man, I didn't claim any of this. But now that you say it, yes, they actually are. People running linux at home essentially are their own sysadmins, people who run linux at work tend to rely on a sysadmin to do all the adminstrative crap for them.
The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
It being ignored by users does not mean it's not the primary user interface anymore. You simply cannot completely admin/fix your system with a shiny GUI. So strictly speaking, the shell is the *only* real user interface.
4) Systemd is really simpler to learn that shell script.
I'm starting to wonder whether you're missing the point on purpose, or whether it's actual bad reading comprehension. I'll repeat myself, once more: Learning systemd helps you at doing systemd-specific stuff. Learning shell helps you at using your OS. Those two things have a large difference in scope of applicability.
* Sysadmins are a minority of Linux users.
Yet, they are fully exposed to all the shitstorm, and their job is to shield the users from that. So quite an important minority, if at all.
* Distributions like Debian support /etc/network/interfaces with systemd.
So what?
* There are sysadmin already using systemd.
So what? There are even more sysadmins running Windows networks and big monolothic "networking appliances"
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
That's only if you're ignoring existing solutions.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
So what? Also, what does "there are still there" mean?
* Still, a lot of forum get post from 'sysadmin' complaining.
Yes. Do you really believe this would be the case if there was nothing wrong with systemd?
Note that all questions are of rhetorical nature, i'm not going to feed you any more.
SysVinit and endless variations like it such as OpenRC
OpenRC is a variant of the BSD rc mechanism, you pleb, which exactly avoids
mixing code and config statements
this.
No, by definition helper scripts must already be part of the distribution.
I completely disagree, but I wasn't aware of that there's an accepted definition. Mind sharing the source?
[...] system V init helper scripts.
I'd hesitate to call the sysV init scripts "helper" scripts, because they are the central mechanism (apart from lil' init itself). The "central element" of systemd are the parts witten in C, of which there (apart form init itself) is no such equivalent in system V init.
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration.
No. I knew you'd bring up something like this, but, no.
The manual way to configure an interface is one execution of the ifconfig(8) program (or whatever is currently hip in the linux world). This is the part that has to be "learned"; you have to remember that the program's name is ifconfig, and that it accepts an interface name, followed by an address family, followed by an address. Or else, that there's a man page. That's the "hard" part, and it's the same (modulo constant NIH-ing of the interface configuration programs due to what probably is an underlying design flaw) on both sysVinit and systemd machines
Now, system V runs that command in a shell script and that's it. If now you feel like objecting "but it means i need to learn the shell!", then here's the important piece you're missing: If you're using a unix-like OS, and you don't know how to handle a shell, then there's your problem. It's the primary user interface. It's not only for running init scripts but provides a direct value for almost every other task imaginable.
Now, in systemd, one has to additionally learn systemd. It doesn't mean you can forget your shell. It does mean, however, that you have to invest significant time to understand and learn the huge piece of shit that is systemd. Apart from professional sysadmins, whose time would be better spent administering their systems, I don't realistically see anyone else going to do that. It's video tutorials and just-do-this-special-trick wiki articles all the way.
Speaking of, is proper documentation at least theoretically available now?
Sysadmin are not the only users of Linux. Real sysadmin already known that leading distributions support the usual way of configuring a static IP address even with systemd. Proactive sysadmin already have learned systemd and are ready to manage it if it's not already the case. There is just a noise from a minority of 'sysadmin' that are neither maintainers, nor proactive, nor willing accepting that systemd will not be the end of the universe, and so frustrated that there can only wrote there distress in the forums.
Hahahahah.
New reactor designs don't solve the root problem of human error
No, they won't. But they limit the consequences of human error, which is sufficient.
What kind of arguments do you need here, this follows from common sense. Do you understand what "baseload" is? Hint: It's always there.
Another hint: There's a world outside mum's basement, and guess what? It's not always windy and sometimes it's (gasp) dark.
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
, exactly the same amount of file on system V init.
Not quite, but whatever.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.
, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
(I mostly agree with this, but it's beside the point)
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English.
Fair enough. So a twisted parallel universe it indeed is! (just kidding)
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications
Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.
and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.
How aren't they related to systemd? I'm not following, I think.
The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
So you see how pointless it is?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.
Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.
Why do you put whitespace in front of question marks?
Editing an init script is never the solution to a problem unless you ARE the maintainer of the distribution.
Or, you know, when there's a way to identify and communicate with said maintainer.
But does the tail meow when you pull the head?
This at +5 Interesting made my fucking day. Hahahahahaha.
Exhaust pipes -- miracles of modern engineering and a fundamental piece of the stability and stiffness of every car!
I sure did look at it (and it made me laugh *even* harder, but that's beside the point).
I'm sure willing to believe that you "know better than me" how to deploy big monolithic number crunchers "globally for a living". Unfortunately for you, this was about networking. (It's a fairly new idea, you might not have heard of it yet).
So I'd suggest you familiarize yourself with the fundamentals of networking, in order to avoid making yourself look like a complete idiot next time
Well, there is probably a lot of even more complicated methods.
I'm sorry to hear it.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I hope this one is simple enough for your use case.
No, it's not; and more to the point, I don't have a real "use case". As said:
The other day I had a spare machine sitting around [.........] [and then] I nuked [it]
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):
printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0
printf 'defaultroute=(gateway addr)' >>/etc/rc.conf
I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.
So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki
Persistent configuration on boot using systemd
/etc/conf.d/net-conf-interface
/usr/local/bin/net-up.sh
/usr/local/bin/net-down.sh
/usr/local/bin/net-{up,down}.sh
/etc/systemd/system/network@.service
First create a configuration file for the systemd service, replace interface with the proper network interface name:
address=192.168.1.2
netmask=24
broadcast=192.168.1.255
gateway=192.168.1.1
Create a network start script:
#!/bin/bash
ip link set dev "$1" up
ip addr add ${address}/${netmask} broadcast ${broadcast} dev "$1"
[[ -z ${gateway} ]] || {
ip route add default via ${gateway}
}
Network stop script:
#!/bin/bash
ip addr flush dev "$1"
ip route flush dev "$1"
ip link set dev "$1" down
Make both scripts executable:
# chmod +x
systemd service file:
[Unit]
Description=Network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/net-conf-%i
ExecStart=/usr/local/bin/net-up.sh %i
ExecStop=/usr/local/bin/net-down.sh %i
[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.
Source
/. wouldn't let me comment without it
/var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.
Your comment has too few characters per line (currently 24.9).
Please ignore everything below;
The log file is expected to reside in the
Hahahahahahaha.
Oh wait, you're serious? Let me laugh even harder...
not sure why this is at -1
Yep, and that number doesn't even include (managed) switches and good firewalls
How did it take you that long to read the handful of comments that existed at the time?
because it couldn't make more clear how (as per /. etiquette, of course, I know) directly jumping to the comment section is your usual MO, when in reality, the occasional guy who actually does spend a few minutes on reading TFA is not unheard of. :).
/. the way I do, which is skimming the front page for stories of potential interest (i know, i know), opening them in background tabs, and only /then/ going through the opened stories, eh, comment sections, one by one. So there's quite a delay between clicking on a story (causing comments to be loaded), and actually looking at it for the first time.
Therefore it could have been a funny and subtle troll as well; thanks for ruling out that possibility
Besides, It's also very possible that the poster just reads
Not sure if I should mod you funny or troll, so I'll comment instead.
I like to keep FF running all the time, too, but it (or the javascripts on certain sites) consume just too much CPU. here's my crude cure
/tmp/.ffstopped ]; then /tmp/.ffstopped /tmp/.ffstopped
#!/bin/sh
if [ -f
pkill -CONT firefox; pkill -CONT npviewer; pkill -CONT plugin-container
rm -f
else
pkill -STOP firefox; pkill -STOP npviewer; pkill -STOP plugin-container
touch
fi
I.e. it's kind of a toggle. Works best when bound to a key combo of the window manager or so. Process names might also differ on Linux
Actually with all the 3rd party javascripts on here, I'd like to correct my estimate to about 40-50 machines.
Try get a basic clue on what comprises a network.
There were probably around 10-20 machines involved in you posting this comment here. One of them runs Windows.
Standards don't mean a damned thing because standards change
wtf? for instance?