Who likes interviews? Me neither. Well, depends…
If you get any of the following questions during an interview then either the interviewer did read this one or he’s getting info from the same sources as I am. Either way, let’s get one step forward.
Suppose you log into a node and find the following situation:
# ls -la /bin/chmod rw-r--r-- 1 root root 56032 ian 14 2015 /bin/chmod
Is it fixable?
… yes. Most of the time. Let’s remember how the executables are being started on Linux: with a system loader, ld-linux-something. Let’s check:
# ldd /bin/chmod linux-vdso.so.1 => (0x00007ffdf27fc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb11a650000) /lib64/ld-linux-x86-64.so.2 (0x00007fb11aa15000)
OK, got it:
# /lib64/ld-linux-x86-64.so.2 /bin/chmod +x /bin/chmod
Fun, isn’t it? The follow up question obviously is “what if the loader’s rights are unproperly set” or something similar. The answer to that is that not all the filesystem issues are fixable with easy commands. One may even have to mount the file system on a different installation (e.g. from a Live CD or attach the virtual storage to another, “good” node) and fix things up from there.
Continue Reading →
DevOps: some people think it’s a hype, a sysadmin job redefined, other people believe it’s just another skill you get from some training or out of school. It’s neither. I personally would say it’s a combination of skills; you get some from school, other from formal training and the rest from the daily hands-on job.
Why is it not just some SysAdmin job redefined?
A “classical” SysAdmin does not use complex automation tools. His/her usual job is to go from one node to the other and set configurations, install software and fix things that do not work;
A normal SysAdmin job does not (usually) involve coding, apart from small scripts that run on individual nodes;
The “classical” SysAdmin (usually) deals with physical nodes and a good part of his/her daily job is fixing storage issues (rebuilding file systems, restoring from backups), debugging various hardware incompatibilities and applying patches.
Why do (serious, formal) coding skills matter for a DevOps?
The current industry trend is to express infrastructure through Code. You can currenty spawn entire environments (e.g. in AWS) with properly sized hardware configurations and services installed through Code only; this is possible with Automation tools like Chef. This is not about simple scripting skills but there are no complex algorithms either.
As I have just mentioned, DevOps is defined through Automation as the node interaction is no longer almost entirely manual. One now runs commands to multiple nodes at once and employs various automated monitoring tools that raise alarms and (sometimes) trigger tasks that do fix those issues, including, but not limited to, scaling resources or even adding new nodes to some cluster.
Who needs DevOps skills? I think that any organization that employs a large computing environment, large enough that scaling through classical SysAdmin operations is no longer feasible or cost-effective. Or, for that matter, any organization that intends to move its infrastructure to the Cloud. Being a new position that cannot be put in the same category with Devs, SysAdmins or QAs, there may be difficulties in filling up the job requirements, the career path or even deciding the compensation, but things are starting to change.
This was my introduction to the DevOps concept. Thank you for your read!
This is a quick’n’dirty tutorial on how to get e-mail working on a basic Linux (Redhat/Fedora/CentOS) installation like the one you may get if you deploy a node in AWS with a predefined AMI (Amazon Machine Image).
The Redhat linux distributions come by default with postfix as MTA (Mail Transport Agent) and Cyrus IMAP as the MDA (Mail Delivery Agent) so this small tutorial is focused on these. Having the packages installed we can go to the configuration files:
/etc/postfix/main.cf: the postfix file, where we configure which e-mails we accept and what to do with them.
/etc/imapd.conf: settings for Cyrus IMAP – where to look for the mailbox passwords, what authentication mechanisms should be supported for pop/imap.
/etc/sasl2/smtpd.conf: for smtp authentication, if an e-mail relay is required (NB: this file can also be located in /usr/lib/sasl2/smtpd.conf).
There is also another file, /etc/cyrus.conf that usually contains the proper defaults upon installation so there may be no need to look into that. It contains settings like the supported protocols (pop3/pop3s/imap/imaps) and the lmtp socket location (the interface between postfix and Cyrus IMAP).
In the postfix configuration file, the following settings are essential:
# cat /etc/postfix.main.cf ... mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp virtual_transport = $mailbox_transport virtual_mailbox_domains = /etc/postfix/virtual_domains virtual_mailbox_maps = hash:/etc/postfix/virtual_maps ...
Explanation: the e-mails for the domains specified in virtual_mailbox_maps are to be, before anything else, accepted for further processing. The final mailbox must be determined by looking into virtual_mailbox_maps (if no such mailbox is determined, some error will be returned to the sender). The effective delivery should be done through the socket specified at mailbox_transport.
Some example file contents:
# cat /etc/postfix/virtual_domains brainware.ro # cat /etc/postfix/virtual_maps email@example.com brainware.ro/john.doe
The “virtual_maps” file is to be “hashed” with postmap (have a hashmap generated out of it):
# postmap hash:/etc/postfix/virtual_maps
On the Cyrus IMAP side, we must first check that the daemon listens on the proper lmtp socket (by default it should):
# cat /etc/cyrus.conf | grep lmtp lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
NB: at this point one may want to disable SELinux in order to allow for the socket communication between postfix and Cyrus IMAP.
Continue Reading →