Focus-follows-mouse coupled with the disabled Raise-on-focus window property is a mode of operation for a window manager, highly targeted at the professional use, unheard of in the Microsoft Windows world. Yet, it takes some fine configuration tweaks to get it to the prime-time. Read More
A Unix heaven is, in my opinion, where everybody in an organization is a Unix user and has a Unix account, be it on a centralized mainframe or on a personal workstation. I could dream of that forever, despite the cruel reality being that even if everybody was a user,
A user is really nothing more than a number.
— as they say in the Chapter 8 of the “UNIX and Linux System Administration Handbook.”
Notwithstanding this profound simplicity, user management even in a standalone system, let alone the modern global Unix clusters, is still a significant operation. And when it comes to user management in distributed systems, Microsoft’s Active Directory is an important player, apparently more important than LDAP, the usual suspect in the field.
And by the way, group management is an interesting topic too. Gotta go play with the group passwords…
Every time I need to mention some automation development work while talking to a client, I find myself overly watchful not to say the words “scripting” or “script” excessively. That’s how much of “sloppiness” is felt to be connotative to those terms in the public opinion.
Ergo, you can see how glad I was to find in the Chapter 7 of the “UNIX and Linux System Administration Handbook” this understanding that
There’s no real distinction between “scripting” and “programming.” Language developers sometimes take offense when their babies are lumped into the “scripting” category, not just because the label suggests a certain lack of completeness, but also because some scripting languages of the past have earned reputations for poor design.
Of course, the importance of scripting cannot be overestimated as it is the main mediator in performing administrative changes reliably, in a consistent and repeatable manner, which are so important in the system administrator’s job as in no other “soft” profession.
Speaking of the subtle differences between “scripting” and “programming”, one could point out the issue of computing system efficiency. Indeed, “scripted” procedures are often several times “slower” than “programmed” counterparts. Administrative work, however, is more about the effectiveness of the administrator, which is the efficiency of the binding administrator+computing_system. As the book authors put it,
Optimization can have an amazingly low return on investment, even for scripts that run regularly out of cron.
Which is more significant out of the two Linus Torvalds’ biggest invetions: Linux kernel of Git? – another great question from the book. On one hand, Linux (albeit not the kernel alone) in this very 5th edition of the book has ousted all the other Unix systems of other editions, including commercial ones – so, perhaps it is quite important. On the other hand,
Mistakes are a fact of life.
That’s another great sysadmin’s dilemma: do you do updates often, trying to keep your systems at the “cutting edge” and have all the security patches upplied immediately upon official release, or do you roll the updates out as discretely as possible, not trying to fix something that’s not [still] broken? That, and the fine topic of PXE, is discussed in the Chapter 6 of the “UNIX and Linux System Administration Handbook”.
On one hand,
gratuitously upgrading systems costs time and money
…
Those who put these principles into practice must be willing to collect an extensive catalog of active releases.
On the other,
Patching outdated versions of the operating system is often infeasible, so administrators are faced
with the choice of skipping updates on some computers or crash-upgrading these machines to a newer internal release.
So what do you do? That’s your artful choice of balance between the two extremes.
Another controversial point of the chapter, about the notable superiority of APT over YUM – they go as far as talking of APT as a superset of YUM, – makes me once again question, why would someone willfully choose Red Had or CentOS over Debian or even Ubuntu, barring the corporate pressure?
Yet another boring chapter, Chapter 5 the filesystem in the “UNIX and Linux System Administration Handbook”, bar the excellent overview of the ACL topic, still has a bit of fun going on.
Linux defines a set of supplemental flags that can be set on files to request special handling.
The immutable and append-only flags (ianda) were largely conceived as ways to make the system more resistant to tampering by hackers or hostile code. Unfortunately, they can confuse software and protect only against hackers that don’t know enough to usechattr -ia. Real-world experience has shown that these flags are more often used by hackers than against them.
The problem of the immutable attribute presented for the configuration management systems is also mentioned. I tend to agree with that with one caveat. Sometimes there are complex administration domains intersections in place, so that it is easier to make a pin-pointed adjustment with the immutable attribute at a leaf system than to introduce changes at a higher lever.
An example of such a situation is using a “managed” virtual machine from a big cloud provider. It is often convenient to have a VM centrally “managed”, but just a little extra local flexibility is well-warranted sometimes.
This is from the Chapter 4 about the process control of the “UNIX and Linux System Administration Handbook” – once again systemd ripples the waters and, IMO is almost a clear winner, despite the hesitation expressed by the book authors.
systemd timers is a feature superset of cron, and rather huge one at that. Out of six systemd timer types only one(!) is a direct representation of what cron is usually in charge of: OnCalendar. (Sure, some implementation of cron are capable of meta time specificators, like @reboot, which is yet another timer type – OnBootSec – in the realm of systemd, but anyway.)
What I personally like about systemd timers are:
AccuracySec. This is a cool substitute for the hackish random delay tricks for the classic cron, which is a must for large server farms managed by a CM system.AND operator for OnCalendar time specifications instead of cron’s traditional OR. It was always a great mystery to me why cron had it as OR from the conception./etc/crontab /var/cron/tabs /var/spool/cron /etc/cron.{d,daily,monthly,weekly} etc). With systemd it is a simple systemctl list-timersSadly, quite a few things still go vague, even after a review by such a great cohort of world-famous admins:
DATA (SIZE in FreeBSD) field is hidden from the top display for a reason. This piece of data is rather useless, at least compared to the RES item, or am I still missing something?strace usage examples could be a little more practical, because when you first try it, it is either too simple, like with tracing cp, or too complex, like with monitoring firefox.Nothing prevents you from changing the username on this [root] account or from creating additional accounts whose UIDs are 0; however, these are both bad ideas.
That was the most profound saying in probably the most boring chapter of the “UNIX and Linux System Administration Handbook”, Chapter 3, about the root account and related topics.
Still, it provides some interesting points, notably about Mandatory Access Control (MAC) and Role-based Access Control (RBAC).
Interestingly, these are the areas where Linux has been lagging behind Microsoft Windows, only having discretionary access control facilities taken from the classic Unix. Proprietary Unix variants, like HP-UX, AIX and Solaris have been closer to leading the way here.
A cool approach at building SELinux policies is mentioned in the chapter. A tool (audit2allow) compiles a policy from the policy violations triggered and logged. Clever, though not foolproof.
Another controversial practice suggested in this chapter is the rule of using sudo for all administrative work.
It is a non-trivial question of what is ultimately more secure: entering a password every 5 minutes for sudo or having a root terminal on standby, authenticated just once at session startup and protected by generic Xwindow session protection mechanisms like screen auto lock and biometrics authentication.
Chapter 2 of the “UNIX and Linux System Administration Handbook” talks about the boot process. Nothing special here, except…ever so interesting debate of init vs. systemd.
The main points from systemd opponents being making the system more complex and less modular. Modularity, as we all know, is one of the Unix’ main merits.
OTOH, general Unix evolution trend of the last decade seems to emphasize booting stage ever more in the overall OS lifecycle. Just look at all those compartmentalization, virtualization, scaling and other cloud computing hypes. All of them imply growing application for short-lived OS instances, which in turn imply more proportion of instance lifetime spent in the boot process.
In legacy systems it was not uncommon to see uptimes in the range of 1 or 2 years and several whopping years sometimes. Today, with auto-scaling distributed HA systems, VMs often get spun up for a few hours a day to handle load spikes.
Comparing these two system classes, it is easy to see the importance of boot process optimization: it has become two (sometimes three) orders of magnitude more prominent time-wise nowadays.
Not only systemd cuts time wasted in bootstrapping by fostering parallelism, it also improves on load spikes response time, and streamlines configuration management by reducing shell scripting hackage required to configure complex boot processes.
Conceptually, this part of Unix evolution corresponds well to the general global information processing trends. Those trends lean towards collaborative, cross-disciplinary information processing and interpretation. Similarly, Unix processes and services can no longer remain “strictly modular” in a modern system, if the system architect seeks to optimize the system for best performance and value for the customer. Unix services need to collaborate between each other more closely to reach that target. For that, systemd is clearly suited much better that the venerated classic init.
Today, a good friend of mine Nikolai Dyumin, a seasoned PhD in mathematics, asked me of a recommended book on the Unix system administration topic.
Immediately I recalled of the “Unix System Administration Handbook” by Evi Nemeth “and kids” paper back sample of the 2nd edition I have had and praised a lot since my early student years. It is a Russian translation (one of the best technical book translations I have ever read), pretty used already, nevertheless offering a good deal of timeless Unix philosophy inside.
While the book is still relevant in the terms of general administrator’s job approaches and concepts, a large part of it has become hopelessly obsolete over the past couple of decades of me owning it. Indeed, who still remembers the RS-232 cables or who does add user accounts directly on the host without any intermediary configuration management system or a centralized directory these days?
In an attempt to refine my book recommendation I went ahead and browsed a bit, and lo and behold! the 5th(!) edition of the book, modernly re-titled “UNIX and Linux System Administration Handbook”, just popped up on my screen.
Looking inside the new edition made me realize just how much time has passed!
The book starts by telling us Evi Nemeth, the most renowned SysAdmin ever who is also a sailor, is no longer with us.
One of the Evi’s mottoes listed in preface states “Be conservative in what you send and liberal in what you receive” truly summarizes the essence of the SysAdmin’s character. Think of it. Probably half of the rest of the Evi’s tenets are largely variations on this one. Take for example “Be liberal in who you hire, but fire early” – that’s the same thing, basically!
And then there was the 1st chapter. A few quotes warrant bringing up.
your response to these [stupid] issues [like “I spilled coffee on my keyboard! Should I pour water on it to wash it out?”] affects your perceived value as an administrator far more than does any actual technical skill you might possess. You can either howl at the injustice of it all, or you can delight in the fact that a single well-handled trouble ticket scores more brownie points than five hours of midnight debugging.
– indeed, a system administrator is a psychologist first. Most administrator’s customers just need someone to understand their problem, regardless of the problem’s nature.
Use it [the nano editor] discreetly; professional administrators may be visibly distressed if they witness a peer running nano.
– looks so familiar!
Gartner found that AWS is ten times the size of all competitors combined
Have you ever thought AWS is that large? I haven’t. Doesn’t it qualify AWS as a monopoly?
As a system administrator, it’s in your best interest to befriend data center technicians and bribe them with coffee, caffeinated soft drinks, and alcoholic beverages.
– interesting, why the authors take the hardware specialists for confirmed drunkards? Is the hand work considered easier than the scripting or security testing while drunk? Or is this type of work more depressing?
Anyway, having recommended such a profound book of about 1300 pages to someone who is a scientist, I thought why wouldn’t I read the new edition myself? If nothing else, this’ll:
It just occurred to me that:
So what am I still waiting for?! I’m starting on the quest of “A chapter a day” today with this fine book!