Skip to content

123Unix!com

Easy Automation is here

  • About
  • Ask a Question
  • Automation Services
  • About
  • Ask a Question
  • Automation Services

Author: Alex

  • Home
  • Article posted by Alex

Gmail spam filter now biting itself

Gmail is getting more ridiculous than ever. It now identifies google’s own emails as spam. Previously I would get annoyed about my bank’s or shopping site’s emails buried in the spam folder, but now I’m in peace with the thing – it is just stupid piece of AI, nothing hostile like we’re accustomed to thing of Google.

If you think this was some non-important type of email I could bring up another example from the same haul – that one was a notification from Google about me changing my payment method in Google AdSense – similarly got trapped in spam.

  • 1 Oct, 2021
  • (0) Comments
  • By Alex
  • News

clamscan exclude & include REGEX format

clamscan documentation is silent about which format the application expects for the –exclude=REGEX, –exclude-dir=REGEX, –include=REGEX, –include-dir=REGEX command line options.

Here are the REGEX rules found experimentally:

  1. . is any symbol
  2. * means zero or more occurrences of the preceding character
  3. + means 1 or more occurrences of the preceding character
  4. ^ ancors to the start of the filename or directory name with full path, either absolute or relative to CWD
  5. / is treated literally as a path subdirectories separator
  6. leading / ancors to the beginning of the filename or directory name
  7. trailing / ancors to the end of the directory name
  8. \s \w \S and other escapes seem to have the backslash ignored
  9. buy this point I got bored 🙂

What follows is the listing of the experiments shell session.

$ pwd
/tmp
$ mkdir d
$ mkdir d/e
$ touch d/f d/e/g
$ clamscan d
d/f: Empty file

$ clamscan --exclude-dir=f d
d/f: Empty file

$ clamscan -r --exclude-dir=f d
d/e/g: Empty file
d/f: Empty file

$ clamscan -r --exclude-dir=e d
d/e: Excluded
d/f: Empty file

$ clamscan -r --exclude-dir=/e d
d/e: Excluded
d/f: Empty file

$ mkdir d/e2 d/3e3 
$ clamscan -r --exclude-dir=/e d
d/e: Excluded
d/e2: Excluded
d/f: Empty file

$ clamscan -r --exclude-dir=/e/ d
d/e: Excluded
d/f: Empty file

$ clamscan -r --exclude-dir=^/e/ d
d/e/g: Empty file
d/f: Empty file

$ mkdir d/e2/e5 d/3e3/4e4
$ touch d/{e,e2,3e3}/{e5,4e4}f

$ clamscan -r --exclude-dir=^/e/ d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e/4e4f: Empty file
d/e/e5f: Empty file
d/e/f: Empty file
d/e/g: Empty file
d/e2/4e4f: Empty file
d/e2/e5f: Empty file
d/e2/f: Empty file
d/f: Empty file

$ clamscan -r --exclude-dir=d/e d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e: Excluded
d/e2: Excluded
d/f: Empty file

$ clamscan -r --exclude=d/e d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e/4e4f: Excluded
d/e/e5f: Excluded
d/e/f: Excluded
d/e/g: Excluded
d/e2/4e4f: Excluded
d/e2/e5f: Excluded
d/e2/f: Excluded
d/f: Empty file

$ clamscan -r --exclude=/tmp/d/e d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e/4e4f: Empty file
d/e/e5f: Empty file
d/e/f: Empty file
d/e/g: Empty file
d/e2/4e4f: Empty file
d/e2/e5f: Empty file
d/e2/f: Empty file
d/f: Empty file

$ clamscan -r --exclude=/tmp/d/e /tmp/d
/tmp/d/3e3/4e4f: Empty file
/tmp/d/3e3/e5f: Empty file
/tmp/d/3e3/f: Empty file
/tmp/d/e/4e4f: Excluded
/tmp/d/e/e5f: Excluded
/tmp/d/e/f: Excluded
/tmp/d/e/g: Excluded
/tmp/d/e2/4e4f: Excluded
/tmp/d/e2/e5f: Excluded
/tmp/d/e2/f: Excluded
/tmp/d/f: Empty file

$ clamscan -r --exclude=^/tmp/d/e /tmp/d
/tmp/d/3e3/4e4f: Empty file
/tmp/d/3e3/e5f: Empty file
/tmp/d/3e3/f: Empty file
/tmp/d/e/4e4f: Excluded
/tmp/d/e/e5f: Excluded
/tmp/d/e/f: Excluded
/tmp/d/e/g: Excluded
/tmp/d/e2/4e4f: Excluded
/tmp/d/e2/e5f: Excluded
/tmp/d/e2/f: Excluded
/tmp/d/f: Empty file

$ clamscan -r --exclude-dir=/.e d
d/3e3: Excluded
d/e/4e4f: Empty file
...

$ clamscan -r --exclude-dir=/*e d
d/3e3: Excluded
d/e: Excluded
d/e2: Excluded
d/f: Empty file

$ clamscan -r --exclude-dir=/3* d
d/3e3: Excluded
d/e: Excluded
d/e2: Excluded
d/f: Empty file

$ mkdir d/p\ a
$ touch d/p\ a/file
$ clamscan -r --exclude-dir=\\s+ d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e/4e4f: Empty file
d/e/e5f: Empty file
d/e/f: Empty file
d/e/g: Empty file
d/e2/4e4f: Empty file
d/e2/e5f: Empty file
d/e2/f: Empty file
d/p a/file: Empty file
d/f: Empty file

$ clamscan -r --exclude-dir='\s+' d
d/3e3/4e4f: Empty file
d/3e3/e5f: Empty file
d/3e3/f: Empty file
d/e/4e4f: Empty file
d/e/e5f: Empty file
d/e/f: Empty file
d/e/g: Empty file
d/e2/4e4f: Empty file
d/e2/e5f: Empty file
d/e2/f: Empty file
d/p a/file: Empty file
d/f: Empty file

  • 20 Mar, 2020
  • (0) Comments
  • By Alex
  • /var/log, How-to, Tools

Developer of Operations

When talking about Configuration Management it is important to acknowledge that writing Configuration Management code, or implementing “IaC” is virtually the same kind of work the software developers are performing. You use a professional code editor, abide to a strict set of syntax rules, track changes in Git or another VCS.

As an admin going the Configuration Management way, you effectively become a Developer of Operations for your infrastructure.

To emphasize the significance of the shift in work nature, the authors of the “UNIX and Linux System Administration Handbook” say that approaching CM activities in a different manner, without coordination and software developer attitude will surely result in “a muddle of conflicting or parallel code” and ultimately “the abyss”.

Other notable quotes from the chapter are these:

  • changes should be structured, automated, and applied consistently among machines.
  • People sometimes conflate DevOps and configuration management
  • snowflake model of system administration – when no two systems are ever alike.
  • security implications of this approach, however: the client controls the facts that it reports, so make sure that a compromised client can’t exploit the configuration management system to gain additional privileges.
  • Nothing that runs out of cron, for example, can depend on the presence of an administrator to enter passwords. Working around that constraint inevitably ends up lowering security to the level of the root account.
  • all major CM systems use similar conceptual models,
    • they describe these models with different lexicons.
    • Unfortunately, the terminology used by a particular CM system often has more to do with conforming to a marketing theme than with maximizing clarity.
  • “environments,” both inside and outside the configuration management context.
    • This seems to be the single term on which all configuration management systems agree.
    • They’re an additional axis of variation that can affect multiple aspects of the configuration.
  • A number of projects focus on specific subdomains of configuration management,
    • notably new-system provisioning (e.g., Cobbler) and
    • software deployment (e.g., Fabric and Capistrano)

  • 12 Feb, 2020
  • (0) Comments
  • By Alex
  • Training

Servers are cattle, not pets

This is the essence of the Chapter 9 “Cloud Computing” of the “UNIX and Linux System Administration Handbook.”

Indeed, you need to treat cloud “servers” as disposable, otherwise it is going to cost you more than your existing in-house server fleet – just like with real cattle it would be more expensive to keep even a small herd at home compared to a single, albeit rare-breed super dog.

On other notes:

  • when moving into cloud, system administrator’s role shrinks considerably:
    • – administrators’ duties are shifted from in-house’ to in-cloud’s admins
      • 1) from local servers to IaaS: half (5/10) of the layers to administer are dropped
      • 2) from IaaS to PaaS: another 2/5 is dropped
      • 3) in SaaS virtually no work is left for the in-company system administrator
    • automation
      • – AWS CloudFormation (native, error prone)
      • – Troposphere Python library – eases CF
      • – Terraform

    And a few quotes from the book:

    – servers should be treated as cattle, not as pets

    – A system is said to be cloud native if it is reliable even in the face of unanticipated events.

    – hybrid cloud
    — operating two distinct cloud presences in tandem increases complexity more than proportionally.

    – AWS offers on-site visits from the AWS Snowmobile, a 45-foot long shipping container towed by a semi truck than can transfer 100 PiB from your data center to the cloud.

    – access controls should conform to the principle of least privilege

    – Serverless functions hold great promise for the industry.
    — AWS introduced Lambda, their cloud function service, at a conference in 2014.
    — Google followed shortly with a Cloud Functions service.
    — Several cloud function implementations exist for projects like OpenStack, Mesos, and Kubernetes.

    – Costs
    — new cloud customers are often surprised when costs climb quickly.
    — third party cloud use analyze services to optimize overprovisioning:
    — Cloudability
    — CloudHealth

  • 31 Jan, 2020
  • (0) Comments
  • By Alex
  • Training

openbox followMouse essential configuration

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

  • 23 Jul, 2018
  • (0) Comments
  • By Alex
  • How-to, Tools

A user is just a number

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…

  • 8 Jul, 2018
  • (0) Comments
  • By Alex
  • Training

“Scripting” is not sloppy “programming”

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.

  • 7 Jul, 2018
  • (0) Comments
  • By Alex
  • Training

To upgrade or not to upgrade?

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?

  • 6 Jul, 2018
  • (0) Comments
  • By Alex
  • Training

chattr for hackers

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 (i and a) 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 use chattr -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.

  • 5 Jul, 2018
  • (0) Comments
  • By Alex
  • Training

cron vs. systemd timers

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:

  • Sub-minute (actually it is sub-second) precision. Sometimes it is badly needed.
  • Accuracy specification with 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.
  • Centralized point of periodic tasks management. It’s been daunting me for ages to find the exact place a particular cron job was defined at, with the myriad of cron files and directories throughout the system (/etc/crontab /var/cron/tabs /var/spool/cron /etc/cron.{d,daily,monthly,weekly} etc). With systemd it is a simple systemctl list-timers

Sadly, quite a few things still go vague, even after a review by such a great cohort of world-famous admins:

  • Zombie processes. The nature of zombie processes is described rather vaguely, they are not at all demystified.
  • 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.
  • 4 Jul, 2018
  • (0) Comments
  • By Alex
  • Training