New Year's Resolutions For *nix SysAdmins (cyberciti.biz) 242
An anonymous reader writes: A new year, with old systems. It is time to break bad old habits and develop good new ones. This list talks about new years resolutions for Linux and Unix sysadmins. List includes turning on 2FA on all services, making peace with systemd, installing free SSL/TLS certificates, avoiding laptops with horrible screens or wireless whitelist in BIOS, building Linux gaming rig and more. What resolutions are on your list regarding sysadmin or IT work in 2016?
My new years resolution... (Score:2, Funny)
is 4k baby!
Re: (Score:3)
this is the year ipv6 will take off (again)
Re: (Score:2)
Let's see if Perl 6 will beat IPv6 into takeoff mode.
Re: (Score:2)
Screw it, let's do a Gillette and just jump to 8.
Re: (Score:2)
And Linux on the Desktop. Let's not forget about that.
Re:My new years resolution... (Score:5, Insightful)
They're not trying to force exclusive ipv6 on you, they're trying to make you go dual stack which you absolutely should.
dnssec (Score:3)
maybe i should finally do dnssec. i've been planning to do it for about 5 years.
Re: (Score:3)
It's better to do it now than 5 years ago. Because it's easier to so now.
Also for mailservers like Postfix they now support the use of DNSSEC+DANE-TLS-certificates:
http://www.postfix.org/TLS_REA... [postfix.org]
This means: encrypted SMTP connections between mailservers and man-in-the-middle is not possible.
Re: (Score:2)
Re: (Score:2)
Is it automated to generate new keys yet? My biggest issue with setting up DNSSEC was remembering to update it before the old keys expire. If I forget on a webserver, I could just install a new cert and go on. If I forget on a domain, no one with a cached entry can access it.
Re: (Score:2)
I aim to be fully encrypted, and offer secure versions of all services. Even local NTP on my LAN.
That includes texts and phone calls.
Propaganda (Score:5, Funny)
"making peace with systemd" Might as well make peace with terrorists.
Re:Propaganda (Score:5, Funny)
No peace until systemd is dead.
Re: (Score:2, Insightful)
The most vocal opponents of systemd (whom you mislabel as "systemd trolls") tend to be professional system administrators and professional software developers with decades of experience.
Many of them have been responsible for hundreds of thousands of production servers and desktops. They've used more operating systems than you could probably count. They've dealt with nearly as many different init systems.
These decades of experience has taught them a thing or two. They've come to learn what works, and what do
Re: (Score:2)
The most vocal opponents of systemd tend to be unprofessional system administrators and architects from an unrelated field, with decades of experience on unrelated systems.
Many of them have been responsible for configuring hundreds of thousands of systems in a non-systemd manner. The biggest variation in their system experience is usually whether they use pacman, apt, or yum. They've only dealt with one, or maybe two init systems.
These decades of experience have made them unable to consider anything differe
make peace? (Score:5, Insightful)
systemd was thrust upon everyone and you want us to accept it just because? how about this: document the code, document the interfaces, solidify the ABI, make the code portable, do a security audit instead of trying to force me to use systemd!
my resolution is to uproot systemd's tendrils from an otherwise decent operating system.
Re: (Score:2)
Security audit systemd... Because init scripts are already secure and we wouldn't want to replace them with something that hasn't been audited!
Re: (Score:2)
Seriously, have you even thought about this in any depth?
What's more safe and secure, many tens of thousands of lines of C running in PID0 with root privs, or interpreted scripts each running as root or with reduced privs in their own separate process?
It's obviously the latter. The only compiled code is the shell interpreter, which is well tested and used all over the place with root privs already. And the shell scripts being run are trusted. Now, you can argue all the other points about the downsides of
Re: (Score:2)
Why would you make peake with the enemy? (Score:2)
In particularly one that is trying to destroy all that is good and proper like systemd? Making peace with it would be stupid!
certifications (Score:2)
Redundant (Score:2)
making peace with systemd, .... building Linux gaming rig
My resolution. (Score:3)
New Year's Resolutions For *nix SysAdmins
After 30 years as an admin and systems programmer, finally find out what that damn asterisk stands for.
DNSSEC (Score:2)
I strongly disagree with his recommendation for DNS. That’s because I want to spread DNSSEC.
The problem with services like Amazon Route 53 is they generate DNS records dynamically. That means they need the signing key to be online, on the DNS load balancer, and they don’t bother to do so. If you really need your DNS to be globally distributed (How many people actually look for your domain, anyway? How many times is the answer cached on Google public DNS already?), you should look into CloudFlare [cloudflare.com]
systemd killed the linux server; long live *BSD (Score:3)
No competent administrator would run something as arcane, unreliable, and fragile as systemd on a server, given any sort of choice.
Goals for 2016?: remove those last few linux boxen and migrate the services to *BSD (Open is my choice, but it does have some lag on drivers; have to brush up on writing those, I guess).
Re:Systemd on slashdot (Score:5, Insightful)
This is a problem with "old vs new".
sys V init is old. So are the old, genuine unix wizards.
SystemD is new. So is Pottering and Pals.
The divide comes from "old culture" vs "new culture." The old unix culture adores simplicity, sparseness, and adaptability. The new culture adores easiness, one-stop shopping, and cohesive wholes.
This argument will never really die. The old culture will point out the endless littany of security problems with software like systemd, simply because of the complexity and scope-creep of the project. (this increases its attack surface, and makes it attractive to malware authors and hackers.) The new culture will point out the endless littany of hair pulling and hours spent dealing with obtuse scripts and strange scripting behaviors for things they feel should be solvable with a mouseclick.
These two will never live under the same roof. Both are right, and both are wrong. There are systems and applications where sysVinit makes sense, and is desirable. There are systems and applications where systemd makes sense, and is desirable.
The real sin here is not heresey by either group.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
Re: (Score:2)
I'd mod you up if I hadn't used all my points.
Re:Systemd on slashdot (Score:4, Interesting)
This is a problem with "old vs new".
sys V init is old. So are the old, genuine unix wizards.
SystemD is new. So is Pottering and Pals.
The divide comes from "old culture" vs "new culture." The old unix culture adores simplicity, sparseness, and adaptability.
The "old culture" knows that a server is just part of a bigger process, and reliability and maintainability are more important than simplicity, sparseness (whatever that means in this context), and adaptability. Without something like systemd, Linux cannot be enterprise ready. "Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM. You want something supported by the vender, with standard configuration options, that can be easily understood by everyone on the team. Sometimes the "most elegant" solution is not the best for the business.
Re: (Score:2)
Wrong - it's with systemd that Linux will have a very hard time to be enterprise ready.
Re:Systemd on slashdot (Score:5, Insightful)
The "old culture" knows that a server is just part of a bigger process, and reliability and maintainability are more important than simplicity,
That is why Systemd is fail. Shell scripts have reliability and maintainability. Systemd complicates troubleshooting of the boot process, and requires that we trust code written by a known lame. Remember pulseaudio? I sure do. I spent hours fighting with it.
Without something like systemd, Linux cannot be enterprise ready.
Why?
"Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM.
Only if your goal is to hire sysadmins too stupid to comprehend shell scripts. The problem is that people that dumb are also too stupid to troubleshoot problems. Try hiring some of the many out-of-work qualified sysadmins who actually know Unix, instead of an H1-B or some kid just out of school.
You want something supported by the vender, with standard configuration options, that can be easily understood by everyone on the team.
And that is how vendors have been using Unix since forever. With shell scripts, supported by the vendor, with standard control flow, that can be easily understood by anyone intelligent enough to be a systems administrator to begin with. Your complaint is that the point and click Microsoft-or-Apple-fanboy-wannabe-sysadmin cannot point and grunt his way through poorly implementing Unix configuration. No one who knows what they are doing will have sympathy for that idea, because there are so very many qualified professionals going unemployed right now. It's not hard to get people who know what they are doing, if you try to hire them. You don't want to do that. You want to hire idiots and you want magically good results. But someone incapable of systems administration without systemd will simply fall flat on their face when a problem crops up, and because they're using systemd it will be harder to troubleshoot the problem.
TL;DR: A monkey who can't understand a shell script can't be a real sysadmin anyway. All they can be is a button puncher. They should work in a NOC, and you should hire someone who knows Unix to administer Unix.
Re: (Score:2, Insightful)
Except of course, that the old strategy doesn't work without constantly having sysadmins grooming and spoiling their pets (servers), something they seldom do other than as an afterthought after a long and hard failure. Heck, at some companies I've been to, nobody can reboot any servers without all the admins being alert and starting services manually.
If we are to compete with cloud solutions, we need to treat servers and services like cattle. Slaughter the ones that have problems, diagnose later and bring u
Re:Systemd on slashdot (Score:5, Insightful)
What we need to support is private cloud solutions,
No, junior. That's called a cluster. Cloud computing is when you spin up instances as you need them, and get billed appropriately. We don't need systemd for clusters. They predate it dramatically. And we're already using virtualization, which also doesn't require systemd. If there's anything else old that's new again that you would like explained for you using only short words, let me know. I'm here for you.
Re: (Score:2)
My kingdom for a mod point :) Bravo, Mr. poo! Good way to start a year.
Re: (Score:2)
A good system admin shouldn't be afraid to break something and use the opportunity to fix it and learn something new. They should always be on the lookout for ways to smooth processes and verify documentation.
Re: (Score:2)
A good system admin shouldn't be afraid to break something and use the opportunity to fix it and learn something new.
Along with being willing to pay for a good system admin, a company has to be willing to pay for test hardware in order for IT to be successful. I've definitely worked in situations where I didn't have that, and was expected to do more with less, and then complained at bitterly when there were coughs. Sorry, kids, if you want it done right, you should pay for it to be done right. If you want it done wrong, I'll do my best.
They should always be on the lookout for ways to smooth processes and verify documentation.
And document processes — but it's easy to document your way right out of a job if
Re: (Score:3)
Without something like systemd, Linux cannot be enterprise ready.
Why?
"Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM.
Only if your goal is to hire sysadmins too stupid to comprehend shell scripts.
And there you've just answered your own question as to "why?" Not that their goal is to hire stupid sysadmins, but their goal is, to some extent, to avoid relying on people being particularly competent.
I see this as part of the disconnect between techies and business/manager types, and you're only illustrating it. For those who are pretty good at the tech stuff, they think, "That's ok, I'll just write a custom script, and if something breaks I'll figure it out." Meanwhile, the business guy has been burn
Re: (Score:2)
Unfortunately that includes the people writing systemd.
A binary log that is written to by several things at once if an example of people who have either never heard of a race condition or do not care if the log gets corrupted for example - utter newbie mistake. A computer that won't boot because systemd can't work out what to do with a usb mouse dongle is one of the many examples of how immature the system is despite
Re: (Score:2)
It's hard to run a business relying on everyone to be a bunch of super-hero super-geniuses. Businesses want a solution that's drop-dead simple.
I get that. The problem that they don't seem to get is that we live in a complicated world, and there is no such thing as a simple solution to that which doesn't involve raining fire down from the heavens, a global flood or some other such reset button which is only available in god games. In the really real world, we simply have to deal with complexities. A computer which could solve all its own problems would be smart enough to go on strike.
Re: (Score:3)
Lift the hood on systemd sometime.
I'm not advocating for systemd. Just pointing out why "enterprise ready" to some extent can mean, "doesn't require any special genius to operate".
Translation, the business guy has hired cheap monkeys who turned out not to be able to handle any difficulty.
That's a really dumb translation, and shows you missed the whole point. You might get how the tech works, but you have no idea how to run things if you think the solution is to hire more expensive people. Sometimes you hire very expensive monkeys on the idea that they're brilliant and "worth it", and then they still make a mess of things. If you've actually ha
Re: (Score:2)
Where are these good out of work sysadmins you speak of? In the Los Angeles area, I have found exactly one (contractor). It is pushing me to need to migrate off Samba and onto Windows/AD for our office after a decade. Systemd also pushes me in that direction, as it becomes closer to a Windows type of solution anyway... just not as mature.
And before you suggest a full time sysadmin, we are a 40 person shop and there just isn't enough to justify a full time position. I would much rather pay $135-150/hour f
Re: (Score:2)
Completely bogus argument. Linux has been "enterprise ready" 10 years ago. You probably also think Solaris was not "enterprise ready" before it got SMF, (the
"systemd" of Solaris) yet most enterprise sysadmins hate its guts and Solaris did run a lot of mission-critical things long, long before SMF ever made an appearance.
Incidentally, in actual enterprise-setups, you do fail-over via network elements, not on the machine itself. But I guess you do not know that because you actually have no clue what you are t
Re: (Score:3)
When I read that, I hear the voice from the "mongo db is webscale" cartoons.
Re: (Score:2)
You seem to have zero experience with actual enterprise IT. What you say is straight from a "cloud services" ad, but it has no resemblance to what is going on in the real world, where an application has to work or 10'000 people can go for coffee. And yes, servers may still run many months at a time without reboot. For enterprise applications on server-side it is often a requirement that they can run for an unlimited time.
You also seem to have no actual system administration experience. If you install a new
Re: (Score:2)
HPC is easy: If a job is lost, you just re-schedule it. HPC is also not what most enterprise software does.
Re:Systemd on slashdot (Score:5, Interesting)
I don't buy that init scripts are simple or even particularly adaptable. I've hand crafted a few in my time and they are always a pain in the arse to manage. When you get to the point of having multiple scripts bring called which then call sub scripts and all of them somewhat unique to that machine... It's time to look for something better.
I have not played with systemd extensively, but it seems to have the right idea. While in theory scripts give you more control, in practice they just make it harder to admin the system and make you waste time hacking them. Having it all tied together and controllable from one place is much better.
I used to have a highly customised Firefox install. Eventually Firefox sucked enough to drive me to Chrome. At that point I realised it was better to just adapt my workflow to something better some times, instead of proclaiming it sucks because it doesn't do things the way I did a decade ago.
Re:Systemd on slashdot (Score:5, Insightful)
I don't buy that init scripts are simple or even particularly adaptable. I've hand crafted a few in my time and they are always a pain in the arse to manage.
If a daemon needs a complex init script to manage it, then systemd won't be able to manage it at all, because it can't do everything a script can do. If systemd can manage a daemon, then it didn't need a complex init script, and you did it wrong.
When you get to the point of having multiple scripts bring called which then call sub scripts and all of them somewhat unique to that machine... It's time to look for something better.
If you need that much complexity to run a daemon, then either your daemon sucks or you do. Unless, of course, you're just talking about simple things like script libraries. If those confuse you, perhaps Unix is not for you. Shell scripting is a core Unix feature.
If you could explain cogently what you meant, perhaps you would get different responses. But so far, you're talking bananas. Systemd's unit files are merely a handful of name-value pairs, they don't even need sections because all of the names are unique (even between sections) but they put sections into them anyway because systemd is all about obfuscation, and needless effort. Systemd's "additional functionality" (unit files, cgroups support) could be replaced by a relatively small shell script, based on existing init scripts. Indeed, any distribution which uses script libraries in its init scripts could have done this cheaply. For example, cgroups are a kernel feature manipulated via short, common commands, like creating directories.
I used to have a highly customised Firefox install. Eventually Firefox sucked enough to drive me to Chrome.
I used to use Chrome for Google services. Eventually Google fucked Chrome hard enough to break Youtube ad-blockers. Then I realized that people who use Chrome are Part Of The Problem.
Re: (Score:3, Insightful)
If a daemon needs a complex init script to manage it,
Define complex. 99% of init scripts are handling of the state of the daemon, PID files, configuration etc. Or to put it another way: Every daemon on my system can be started with a single line in the console, why do I need a script to manage it at all?
You are right. Init scripts don't need to be complex. Yet on every system they are still longer than 1 line, actually they are typically longer than 100 lines. I've written systemd scripts (or whatever they are called). I've written upstart ones. I've copied a
Re: (Score:2)
Keeping track of the PID is important if you want to kill the process reliably when it hangs up. (because invoking the executable to tell it to down wont work reliably with a hung process.)
That is, unless invoking ./etc/init.d/foo shutdown is harder for you than doing
ps -A
to find the process ID then doing
sudo kill FooID
I suppose you might feel it safe to use
killall foo
but what if you have multiple instances of the daemon running? (say, different ssh server daemons on different ports)
Taking the time and endu
Re: (Score:2)
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
Re: (Score:2)
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
No, you should have one script and 100 lines in /etc/inittab. Each line should have different arguments, ideally pointing to a configuration file for that particular instance of your daemon, i.e you have 100 differently configured instances of the same deamon. Then init manages them for you.
Re: (Score:2)
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
Systemd's daemon management system, which is based around unit files, is dedicated to the idea that you don't need a multitude of init scripts. And in fact, it's broadly true; most programs fall into one of a very small set of cases. But solving this problem doesn't require a new init daemon. All it requires is a new init script which parses unit files, or something like them. The files get a hashbang at the top which calls the script, which reads the unit file and does whatever needs to be done using the u
Re: (Score:2)
If a daemon needs a complex init script to manage it, then systemd won't be able to manage it at all,
I see...
If you need that much complexity to run a daemon, then either your daemon sucks or you do.
So what you are saying is that some daemons suck and are better avoided anyway. Okay.
Eventually Google fucked Chrome hard enough to break Youtube ad-blockers.
Strange, they work fine for me. There is an issue if you install the YouTube app because, for security reasons, extensions can't screw with apps. Just uninstall the YouTube app and it will go back to loading as fast as in other browsers, but your ad-blocker will work.
Re: (Score:2)
I like many people, have used init scripts for years and very rarely have i had to customise any of them or write my own, and almost always use the standard init scripts that come with the package.
However i do understand shell scripting, so i can see what the init script is trying to do and go through it manually if i need to debug something or if i need to run something in a non standard way (for instance recently i had a hardware failure, so we mounted the drive in another server and brought its services
Re: (Score:2)
That's why systemd doesn't use "PID files". It's a broken concept.
You don't need a PID file if you use init properly.
Re: (Score:2)
because...
...anything that needs to know what the PID of a process to manage the process should not be managing the process. That is what init does, and it already knows the PID.
Typically, a PID file is scripted when you need to maintain a process. If you need to maintain a PID file, chances are you are using a script in /etc/init.d linked to a runlevel entry in /etc/rc.whatever. The use case here is that you want to shut the process down on shutdown *OR* change of runlevel. In that mode you're trying to figure out
Re: (Score:2)
I don't buy that init scripts are simple or even particularly adaptable.
Hang on a minute - are you talking about /etc/init.d scripts that get linked to a runlevel in /etc/rc or a script called from /etc/inittab managed by init? - because they are different.
Using /etc/inittab it's pretty easy to make something a system managed service using init this way, to be either respawned, run once, on or off, from a single file.
Customizing rc level 4 is also an option, for example to make the system boot in a more specific way for a media centre client or something more specific. Ther
Re: (Score:2)
How can you become someone like him? Just make things up and force distros to use it...
Wait a minute, that's not really what happened didn't it?
Re: (Score:2)
I've written about the things that I like, and that disturb me about systemd [slashdot.org].
Re: (Score:2)
If just systemd really was easiness, it's definitely just like fishing in muddy water.
Re: (Score:2, Interesting)
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
Did you just try to make writing software to scratch your own itch sound like a bad thing? If Poettering wants to write systemd-only software, nobody's going to stop him. Nobody should be able to stop him. Nobody's going to force him to create or maintain SysV init scripts either. And if other projects find that depending on systemd is convenient, so can they. Open source is not a democracy. Developers do what developers want, regardless of what their users think and by users I mean everybody from other pro
Re: (Score:2)
Uh huh.
And how did that work out for Gnome3, Ubuntu's choice of Unity, or MS's choice of Metro?
Oh, right. It resulted in a user revolt.
It's a two-way street, even if you don't like that fact. Developers become irrelevent without user satisfaction.
Re:Systemd on slashdot (Score:5, Interesting)
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
Did you just try to make writing software to scratch your own itch sound like a bad thing? If Poettering wants to write systemd-only software, nobody's going to stop him. Nobody should be able to stop him. Nobody's going to force him to create or maintain SysV init scripts either. And if other projects find that depending on systemd is convenient, so can they. Open source is not a democracy. Developers do what developers want, regardless of what their users think and by users I mean everybody from other projects to distro packagers to system administrators to end users. The conflict was lost when systemd was voted in as the default, trying to bend the Debian system to force developers to preserve the old ways was a fool's errand. If it had passed, all that would have happened is that Debian would have lost them. Nobody can make that kind of committee decision stick.
I am a little suprised that someone with your UUID would have such a philosophy about the Debian project, but fair enough. I'd like to refer you to the Debian Manifesto [debian.org], a document that was written when the Debian project was first founded. In particular, I'd like to refer you to section A.3:
thus, a distribution is created based on the needs and wants of the users rather than the needs and wants of the constructor.
, with "constructor" referring to the creator.
To be very clear, I am not advocating that Poettering shouldn't be programming what he pleases, nor that all work should be productive. However, I am saying that at least for the Debian project, the focus (used to be) on the users, and making a solid operating system useful to everyone. There's been a large resurgence in the "developers first" attitude the last couple years, and while it lends itself well to hobbyists, these kinds of people should not be working on a large and collaborative project with the goal of being useful to everyone - because, as you've made very clear, the center of that philosophy is all about your wants and needs, something which is directly contrary to the main goal of the Debian Project (and really, any large open source project whose goal is to be useful to more than the developers).
Re: (Score:2)
The real sin here is not heresey by either group.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
I completely agree. If I could just easily ignore systemd, because whenever I install a new Linux machine, I get offered both alternatives by default, I would not care at all. This way, I have the thing forced on me (or nearly so), which is just not acceptable.
Re:Systemd on slashdot (Score:4, Insightful)
This has been this way for a long time. Redhat maintainers actually wrote a long post about "choice" a decade ago. Their efforts for maintaining a distribution go up exponentially far more than simply maintaining 2 packages with 2 startup scripts if they give the user choice. Their summary was you have choice as far as what distribution you use. Don't like what is being provided, then fork or move to another distribution.
Quite frankly given the poor state of many distributions with regards to unresolved bugs and very slow moving adoptions of features I fully support them not wasting time on trying to please everyone.
Re: (Score:2)
Not just exponentially, but far more exponentially?
Since I'm obviously not as clever at maths as you are, can you tell me the equation for that?
Re: (Score:2)
You want equations look on the RedHat mailing list. The example they cited involved maintaining 2 programs in the distribution, doubling the testing cases for some 50 other programs that now rely on not one but two dependencies, and writing and maintaining a program to allow the user to switch between the two cases.
You can crap on my pre-morning-coffee post all you want, but that doesn't change the facts. The maintainers of a distribution themselves have come out and said WHY they don't provide more choice
Re:Systemd on slashdot (Score:5, Interesting)
I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.
I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.
sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.
systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.
Re: (Score:2)
Same here. My biggest worry was about binary logging - I often will grep thru various logs looking for stuff, even if to just show students what is actually going on when something is happening.
But... my Debian 8 setup, with systemd, still has all the log files I'm used to, in the same places they've always been, with the same information in them. So I don't know if systemd is "double logging" or if Debian set this up to keep us old farts happy.
Re: (Score:2)
For my own part, I've been working on a code review of systemd [slashdot.org]. I spent a lot of time trying to understand why it was getting adoption [slashdot.org]. I've delved into the code and looked at the interfaces.
I suggest reading my reviews, but the end result is this: systemd is a good attempt to solve problems that people have, but it isn't a very g
Not "old" vs "new" (Score:2)
So called "new" culture is just Red Hat trying to force their proprietary crap on everybody by name-calling and shaming.
MS does the same thing. The entire systemd scam is right out of MS's playbook.
Re: (Score:2)
Nice propaganda piece, full of lies and slander. My guess is you still work for that marketing company and got paid to write that.
Re: (Score:2)
Systemd on slashdot? That might go over like a lead balloon from what I've seen herer with some.
Surely you mean a lead (spelled led) zeppelin?
The article is rather insightful and one of the few that are worth reading. I disagree with a few points (2FA for ssh on his personal workstation?!?) but there are some good points in there:
* Make peace with systemd
* Learn the new tools: ip, ss, iw (not on his list, but on mine)
* Learn ZFS (on my list for half a decade)
* Use tools such as Lets Encrypt on all websites (good idea in theory, in practice not feasible due to 3 month certs)
* Learn Android
* Stop
Re: (Score:3)
* Use tools such as Lets Encrypt on all websites (good idea in theory, in practice not feasible due to 3 month certs)
Take it as a good incentive to learn automation.
Re: (Score:2)
Take it as a good incentive to learn automation.
You are 100% correct, and I will in fact address it that way!
Re: (Score:2)
* Learn the new tools: ip, ss, iw (not on his list, but on mine)
ip and ss are massive improvements over netstat, well worth learning. These tools are certainly more evolved than netstat
Re: (Score:2, Informative)
The main arguments against systemd are that it's monolithic
Here is the output of ps -ef | grep systemd on a Ubuntu 14.04 desktop which uses upstart and not systemd as its init system:
root 387 1 0 2015 ? 00:00:00 /lib/systemd/systemd-udevd --daemon /lib/systemd/systemd-logind
root 701 1 0 2015 ? 00:00:00
It's clearly not completely monolithic if you can run two fairly central components without even the init daemon present.
rapidly becoming non-optional
Yes, in some distros. It's entirely up to the distro maintainers what options they want to support. That t
Re: (Score:2)
That's because it's not related to init. Init is one subsystem. systemd, being a process manager, doesn't care if init is included or even when it is started. Once it's started, the communication between the parts are within the systemd communication channels (increasingly). This is what makes it monolithic. SMH
Please correct me if I'm wrong here but what process manager are you talking about? Pid 1 on Ubuntu 14.04 is upstart and it owns both of those two services. They are as far as I can see running completely independent.
Re:I've made my peace with systemd (Score:5, Interesting)
I'm sort of right behind you. I can understand SystemD for creating the tools to make a good desktop. However, tools that make a good desktop do not necessarily make a good server. That's where I see the problem.
I run Linux Mint on my desktop and as long as it works, I don't really care what's under the hood. However, I also maintain servers where I care very much what happens under the hood. For example, I care about being able to read plain text logs and I don't understand what possible reason there could be for storing logs in a binary format. I also don't see the need to have a super complex system configuring my network interface simply because in a typical server environment your IP address doesn't change often, if at all.
I'm definitely looking at FreeBSD again (it's been 15 years since I touched any BSD outside of monowall/pfsense) and am using it for a new project at work that's currently in Alpha testing phase. I'm doing it because it's more in line with my KISS preferences but I will admit that I miss iproute2.
Re: (Score:3)
For example, I care about being able to read plain text logs and I don't understand what possible reason there could be for storing logs in a binary format.
ForwardToSyslog=yes in journald.conf
Everytime I see the complain about journalling in systemd I cry a little. The only thing journald does is allow logging earlier in the boot process before a syslog daemon has even started and give you options. One of those options include outputting everything back to your syslog daemon of choice if you're so deadset against having easy to browse journal entries which provide far more detail than the traditional syslog.
I also don't see the need to have a super complex system configuring my network interface simply because in a typical server environment your IP address doesn't change often,
You mean in *your* typical server environment. System
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'm sort of right behind you. I can understand SystemD for creating the tools to make a good desktop.
No. The boot process is just as important to a desktop as a server, and when systemd breaks the boot process, it also breaks troubleshooting the boot process. There's nothing about a desktop that magically makes you want to do this. Also, all of the functionality of systemd which does not exist in other daemons already extant on the system (i.e. cgroups support) would actually be far more useful on a server than on a desktop... but you can't trust systemd on a critical server, because the boot process is ev
Re:I've made my peace with systemd (Score:5, Insightful)
As an example for the problems with troubleshooting, I've recently installed a few Ubuntu 15.10 systems (bare metal and in VMware VMs). In both scenarios, NFS filesystems fail to be mounted at boot. Why? I have no bloody clue. There's nothing in the logs. If I umount them (they are showing as mounted but give immediate I/O error on use) and remount by hand it all works just fine. No idea how to troubleshoot it. With sysvinit I could boot to an interactive shell in the late initramfs and step through every script by hand, and pinpoint exactly where something was failing. With systemd, even with correctly configured systems, I still experience occasional unrecoverable hangs at boot as it screws up its nondeterministic boot ordering and waits forever on something or other (who knows what it might be). systemd has absolutely not improved boot reliability. If I boot a FreeBSD system with exactly the same NFS configuration, it mounts everything perfectly at boot every damned time.
Another thing, is the broken compatibility with what came before. Example: I edit /etc/nfsidmap.conf to configure NFSv4 id mapping. Previously I'd reload/restart the nfs-common service with 'service' or 'invoke-rc.d'. Job done. What's the systemd equivalent? I don't know, and I can't see any obvious candidate. Since both these commands now forward to systemd, a diligent engineer would have made the old service names forward to the new target(s) to retain compatibility, maybe with a helpful message indicating what the new names were. There's nothing. I don't see any obvious nfsidmap or generic rpc or nfs units. Yes, it's partly me lacking familiarity with the new way of doing things; but the lack of care in having a smooth transition for admins makes for a terrible time, and the mess of units makes the whole thing difficult to comprehend as a whole and baroquely overcomplicated.
Re: (Score:2)
Another thing, is the broken compatibility with what came before. Example: I edit /etc/nfsidmap.conf to configure NFSv4 id mapping. Previously I'd reload/restart the nfs-common service with 'service' or 'invoke-rc.d'. Job done. What's the systemd equivalent?
I would argue that this is actually the distribution's job, but someone certainly should have taken care of it if the goal is to be easy and convenient, which is the usual claim by systemd supporters.
Re: (Score:3, Insightful)
NFS filesystems fail to be mounted at boot. Why? I have no bloody clue. There's nothing in the logs.
Unlikely. If there was an error running the mount command, it was definitely recorded in the log. Did you use journalctl -u nfs or journalctl -b?
With sysvinit I could boot to an interactive shell in the late initramfs and step through every script by hand, and pinpoint exactly where something was failing
You can get a debug shell in systemd. The process is just a little bit different,
http://freedesktop.org/wiki/So... [freedesktop.org]
With systemd, even with correctly configured systems, I still experience occasional unrecoverable hangs at boot as it screws up its nondeterministic boot ordering and waits forever on something or other (who knows what it might be).
I'm sorry, but that's bulls**t. If your system is randomly hanging, then it's not configured correctly. While the boot sequence of systemd can be characterized as non-deterministic, it is not random. If services are hanging because dependencies have no
Re: (Score:2)
I'm not sure what this has to do with NFS. Fails on Ubuntu 15.10 for me. But zero inodes doesn't look like a useful setting. Works with a positive count or if unspecified.
The NFS issue is likely it mounting the NFS filesystem before all the necessary RPC services are working, or something like that.
Re: (Score:2)
If you have to ask then you do not understand the issue. It is glaringly obvious though.
Re: (Score:2)
No. Seriously, if you need to ask then you do not even remotely have the level of understanding and experience this needs. I cannot fix your deficient education and experience.
Re: (Score:2)
I have only modest experience working with *nix flavor boxes, and I fully understand the need for text based logs.
I see no real value in a binary based log, unless you want to attach some kind of diagnostic symbol metatdata to the log. (and if you did that, you had better have a dedicated storage array to store the logs...cause they will get big FAST.)
Basically, you need to be able to read the logs with the most minimal of tools, because you are going to be diagnosing it in a downed state most likely-- You
Re: (Score:2)
Re: (Score:2)
Sounds good... right up to the point when there's a problem. Then what happens? systemd notices that the log is corrupt, and... deletes it. No log of the problem. See: the long and angry (and unfixed) bugzilla tickets.
As for log compression, you don't want the actively written log to be compressed. If there's a problem, even as small as a single bit error, then the log will be unrecoverable. That's the tradeoff you make with compression. logrotate compromises by only compressing older logfiles. If t
Re: (Score:2)
As for log compression, you don't want the actively written log to be compressed. If there's a problem, even as small as a single bit error, then the log will be unrecoverable. That's the tradeoff you make with compression. logrotate compromises by only compressing older logfiles. If there are any minor errors in the active log then you can still read it just fine.
Excellent point and one that, again, requires just a bit of the respective real experience and understanding the systemd developers seem to be so sorely missing.
As to log-deletion on corruption, that is the most bone-headed stupid design. Flag it as corrupt, but let people read them! And keep them! My guess here is that the systemd developers are too inexperiences to come up with a robust binary log format, but are unwilling to go back to the sane choice, because they are too much in love with their creatio
Re: (Score:3)
systemd notices that the log is corrupt, and... deletes it
That's not what happens.
See: the long and angry (and unfixed) bugzilla tickets.
Which one? The one that says journald will rotate the log on detection of corruption, thereby preserving it in an un tampered state while still allowing the uncorrupted portion to be read?
Re: (Score:2)
Integrity checking is utterly worthless if availability is not ensured. An attacker on a systemd-binary-log box can just corrupt the logs or throw them away himself, no need even to fake a credible one. As systemd is known to do that from time to time by itself, this does not raise suspicion. On the other hand, credibly faking or completely excising traces of an attack from a text-log is quite a bit of work with a real risk of screwing up.
The level of non-understanding exhibited by this design is scary.
Re: (Score:2)
I have only modest experience working with *nix flavor boxes, and I fully understand the need for text based logs.
It is not a difficult insight to have. That is why somebody asking the question is either trolling or really has no experience with situations where you need the logs. In the second case it is very hard to enlighten them. You had to be there. In the case first they do not want to find out.
That said, you list some of the most important reasons to avoid binary logs. In particular the "easily damaged" aspect seems to be a real problem with systemd and it is an invitation to any attacker to just corrupt the log
Re: (Score:3)
Basically, you need to be able to read the logs with the most minimal of tools, because you are going to be diagnosing it in a downed state most likely-- You cannot bank on having a full suite of binary manipulation tools on hand. You will be lucky if you have more than vi.
This is the biggest load of canned bullsh**t argument. Where do you guys come up with this crap? We don't work on 1970s mainframes anymore. Why would vi be the only thing available? Why would an emergency shell not have the journalctl utility? Why would there not be serial logging capability? Why would you not be able to boot with a rescue disk (in case all other things fail)? The answer is, there is no reason. It is a made up scenario that doesn't exist.
Also, text based logs compress REAALLY well for long term storage for audit purposes! Binary logs? Probably not so much.
More bulls**t. There is no reason to think the journa
Re: (Score:2)
You wish. But classical pro-systemd propaganda: systemd knows best and all other have to justify themselves, even on the most obvious and trivial things.
There is a large body of knowledge out there how to do these things right. Those that insist that body be quoted whenever somebody criticizes systemd are ignorant fools. And by the time-honored principle "if it is not broken, do not fix it" it is always the new thing that has to justify itself, not the old one that has been working for decades.
Re: (Score:2)
And you can of course choose to use rsyslog if you want to. Just enable syslog forwarding,
...and pray that if there is a problem with systemd, the log entries still actually make it that far, which is not a foregone conclusion.
The single worst thing systemd did was fuck up logging. There was no need for it. They could have added binary logging to any existing syslogd. Instead, NIH, because Poettering. But based on experiences with pulseaudio, he can't code his way out of a nutsack. Now he wants control of the boot process, after fucking up the audio process for years. And you want to give it to
Re: (Score:2)
I made my peace nearly 10 years ago when I bailed on Slakware (and I was one of its early adopters in the 90s). While I did like the underdog status of NetBSD, I settled on FreeBSD, have not looked back and use it on servers, desktops and even a laptop (gasp!). Perhaps I'm more easily satisfied because new shiny never was a big thing to me.
Re: (Score:2)