How To: Filter RSyslog Messages by String

I think I’m pretty much done with the Centralised RSyslog server project – it’s finally in the stage I’m happy enough with. One of the final touches I needed on the server side was to filter more important messages into a separate file, so that I can tail that file instead of looking at all the RSyslog messages arriving from all the servers and appliances.

Why You Might Want to Filter Syslog Messages

Most of the reasons are around focusing on specific subset of the logs.

IMPORTANT: I want to highlight that there’s filtering where you drop (ignore) messages and filtering where you just forward certain logs to separate files. In my opinion, you should never discard logs – the risk of missing something important is just too high.

So collect everything, but filter it into separate files and only inspect the more useful elements. The rest is stored and quite possibly rotated very often – meaning you’re not really wasting that much space. But in a case of some security incident you’ll expand research surface and will look into all the logs and not just the usually important ones.

Specific reasons for filtering Syslog Messages

  1. You have multiple teams or team members with different responsibilities – someone needs to look at application logs, someone else at OS services logs
  2. You have specific processes that run regularly and need monitoring – for instance, auto-deployments or cron-based automations – they use the same common tools like HTTPS for git hooks or SSH for remote access or SUDO for privilege escalation – but will be lost among other standard traffic about HTTPS, SSH and SUDO
  3. You have parts of logging providing additional, non-essential information – like, when you ssh onto a server, you have pam_unix session management messages that you may not be interested in. It’s important to know when someone’s unsuccessfully trying to SSH, but not nearly as important to track when someone logs in or out.

How To Filter Syslog Messages by Expression

Relatively new approach is using expression-based filters in RSyslog – they’re using a common and readable enough format of if-then:

 if $msg contains 'ssh' then /logs/security.log

How To Filter Syslog Messages by Application/Service

It’s also super useful to filter by program name – this is essentially a process name.

For instance, in this syslog line highlighted sudo is the program name and not the text of the logged message:

Mar 29 09:45:38 s7 sudo:    greys : TTY=pts/0 ; PWD=/home/greys ; USER=root ; COMMAND=/bin/grep -E ^pi: /etc/shadow

The following RSyslog example helps me extract only sudo lines with COMMAND into /logs/security.log file. Any other sudo lines will not be captured in /logs/security.log, but will still be captured elsewhere.

if $programname == 'sudo' and $msg contains 'COMMAND' then /logs/security.log

See Also




rsyslog parent startup failure: error reading "fork pipe"

RSyslog

I’ve been configuring my OpenMediaVault NAS server for RSyslog shipping logs to my centralised RSyslog setver, when I experienced a cryptic error:

rsyslog startup failure: error reading "fork pipe": No such file or directory

rsyslog didn’t start, so it took me a bit to investigate.

Turns out, the issue was mismatch of RSyslog config syntax: OMV used one version, my templates used another.

Specifically, I’m using old-syntax multi-line way of describing global TLS settings for configuring client side of RSyslog:

global(
         DefaultNetstreamDriver="gtls"
         DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca.crt"
         DefaultNetstreamDriverCertFile="/etc/rsyslog.d/helios4.crt"
         DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/helios4.key"
 )

But earlier in the file I used a more recent way of configuring RSyslog modules:

module(load="imtcp")
input(type="imtcp" port="514")

It seems RSyslog doesn’t suppot this kind of mixing config styles – so one of these config stanzas needs rewriting. In my case, I actually only needed imtcp for debug purposes – so I just commented it out and RSyslog restarted just fine.

See Also




Migrate iptables to nftables in CentOS 8

iptables to nftables

Although Ansible provides support for managing firewall rules via module, I still find initial setup is best done with a tested batch of firewall rules instead of adding them one-by-one. Since I’m migrating CentOS 7 servers to CentOS 8 now, I decided to convert iptables into nftables.

Will probably post a Unix Tutorial Project about this, but today I’m just capturing notes.

What is nftables?

nftables is the next (current) generation of NetFilter based firewall solutions, replacing iptables and providing backward compatible tools with iptables syntax.

If all you used before is iptables, you can continue using familiar commands – but in CentOS 8 this means that on the firewall level there’s no longer iptables running, all the functionality is provided by NFT.

How To Save iptables rules/chains into a file

# iptables-save > /etc/sysconfig/iptables.current

How to Convert iptables rules into nftables rules

# iptables-restore-translate -f /etc/sysconfig/iptables.current > nft-rules.txt

IMPORTANT: make sure you put this into some nft-rules.txt file outside of the /etc/sysconfig location – if things go wrong, you’ll just reboot server via hosting console and regain access.

Try/Check NFT Ruleset

Now comes the moment to disable iptables and try NFT tables in their place.

I did the following: flushed IPtables (removed any rules) and then applied NFT rules.

Flush iptables

# iptables -F

Apply NFT rules from nft-rules.txt file

# nft -f nft-rules.txt

We can now have a look at the list of active NFT rules:

# nft list ruleset

Configure nftables Rules to Apply upon Reboot

Assuming everything works as expected, we can now move the nfs-rules.txt file into default location that will be used by NFT upon reboot:

# mv nft-rules.txt /etc/sysconfig/nftables.conf

Make sure it belongs to root and has correct permissions (it’s not a script so needs no execution bits):

root@s1:~ # ls -lad /etc/sysconfig/nftables.conf
-rw-------. 1 root root 5227 Mar 12 01:48 /etc/sysconfig/nftables.conf

See Also




How To Check SSL Connection with OpenSSL

OpenSSL

I’m tidying up Centralised RSyslog setup on the newly reinstalled becky Raspberry Pi system. One of the tasks at hand was to configure TLS based encrypted log shipping from my dedicated servers to home RSyslog server, this post shows the command and technique I use.

How To Check SSL Connection

What we do is run openssl command with the s_client option and specify remote server we’re testing connection to. It can be an HTTPS connection (port 443) to a website (will do a post about it some other time), but in my case I’m connecting to home office server becky.ts.fm with port 6514 (TLS encrypted port for Syslog):

root@s2:/ # openssl s_client -connect becky.ts.fm:6514
 CONNECTED(00000003)
 depth=0 CN = becky.ts.fm, O = Tech Stack Solutions, L = Dublin, C = IE
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0 CN = becky.ts.fm, O = Tech Stack Solutions, L = Dublin, C = IE
 verify error:num=21:unable to verify the first certificate
 verify return:1
 Certificate chain
  0 s:/CN=becky.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
    i:/CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIEJDCCAoygAwIBAgIUJGqZcuyXa7ekrK+U8yfB2Cu54FYwDQYJKoZIhvcNAQEL
 jMNHiZ0zdzolHWzkV6iKc20MxOv3ftQ1TsE7vg+/Z2fTSv2f0uirPZUPegSzwr75
 ABRIDGED
 9n7UHknn7/mV+lLcloOA8oyXB5zeVf+lxLufVRyhEIpLFVtRiu0Go6PW0gjwMoPM
 QB/0E6WgtSDMf43f9qzSdtKNgHFw1MpxVQdULSabnI6n0gpfuUIvKDBmBazgh6lR
 RtZqUqzO9pE=
 -----END CERTIFICATE-----
 subject=/CN=becky.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 issuer=/CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Acceptable client certificate CA names
 /CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Client Certificate Types: RSA sign, DSA sign, ECDSA sign
 Requested Signature Algorithms: RSA+SHA256:0x09+0x08:0x04+0x08:ECDSA+SHA256:0x07+0x08:
RSA+SHA384:0x0A+0x08:0x05+0x08:ECDSA+SHA384:RSA+SHA512:
0x0B+0x08:0x06+0x08:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
 Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:
ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
 Peer signing digest: SHA512
 Server Temp Key: ECDH, P-256, 256 bits
 SSL handshake has read 1704 bytes and written 427 bytes
 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 No ALPN negotiated
 SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
     Session-ID: 224B0D3C5183426D7DDAD5A5FB361BC9C5175EC9CB0AA6A2F396DAAEE7178080
     Session-ID-ctx:
     Master-Key: 6BE67A8AD4E22029DE1B3D0DE1F4351FD0488AB1D8ABC7E25187
     Key-Arg   : None
     Krb5 Principal: None
     PSK identity: None
     PSK identity hint: None
     Start Time: 1583790681
     Timeout   : 300 (sec)
     Verify return code: 21 (unable to verify the first certificate)

As you can see, ther is a problem. I’m checking the last line in the output, which should return code ok, but it tells me that my s2 server can’t verify the first (only) certificate presented by my RSyslog server becky.ts.fm.

From experience, I konw that’s because s2 somehow needs to acknowledge the certificate authority (CA) that issued certificate for becky.ts.fm.

How Successful TLS Connection Looks in OpenSSL

So if I specify this CA cert as a command line option, openssl will establish TLS connection and confirm code ok:

Now let’s specify the CA certificate I used for RSyslog, the connection and certificates verification should work just fine now:

root@s2:/ # openssl s_client -CAfile /etc/rsyslog.d/ca.crt -connect becky.ts.fm:6514
 CONNECTED(00000003)
 depth=1 CN = syslog.ts.fm, O = Tech Stack Solutions, L = Dublin, C = IE
 verify return:1
 depth=0 CN = becky.ts.fm, O = Tech Stack Solutions, L = Dublin, C = IE
 verify return:1
 Certificate chain
  0 s:/CN=becky.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
    i:/CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIEJDCCAoygAwIBAgIUJGqZcuyXa7ekrK+U8yfB2Cu54FYwDQYJKoZIhvcNAQEL
 BQAwVDEVMBMGA1UEAxMMc3lzbG9nLnRzLmZtMR0wGwYDVQQKExRUZWNoIFN0YWNr
 ABRIDGED
 jMNHiZ0zdzolHWzkV6iKc20MxOv3ftQ1TsE7vg+/Z2fTSv2f0uirPZUPegSzwr75
 9n7UHknn7/mV+lLcloOA8oyXB5zeVf+lxLufVRyhEIpLFVtRiu0Go6PW0gjwMoPM
 QB/0E6WgtSDMf43f9qzSdtKNgHFw1MpxVQdULSabnI6n0gpfuUIvKDBmBazgh6lR
 RtZqUqzO9pE=
 -----END CERTIFICATE-----
 subject=/CN=becky.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 issuer=/CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Acceptable client certificate CA names
 /CN=syslog.ts.fm/O=Tech Stack Solutions/L=Dublin/C=IE
 Client Certificate Types: RSA sign, DSA sign, ECDSA sign
 Requested Signature Algorithms: RSA+SHA256:0x09+0x08:0x04+0x08:ECDSA+SHA256:0x07+0x08:RSA+SHA384:
0x0A+0x08:0x05+0x08:ECDSA+SHA384:RSA+SHA512:0x0B+0x08:
0x06+0x08:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
 Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:
ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
 Peer signing digest: SHA512
 Server Temp Key: ECDH, P-256, 256 bits
 SSL handshake has read 1704 bytes and written 427 bytes
 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 No ALPN negotiated
 SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
     Session-ID: C6797515EEA312D7A9EC6685F895AE004798550FF70619E85F24AB5ACF80F0A9
     Session-ID-ctx:
     Master-Key: 4B84DF3CFE9697EEC634DC271B2A490D94B7A7AB1CA218F016B1ED141FA1479C
     Key-Arg   : None
     Krb5 Principal: None
     PSK identity: None
     PSK identity hint: None
     Start Time: 1583790782
     Timeout   : 300 (sec)
     Verify return code: 0 (ok)
 ^C

That’s it – this means secure connection establishes successfully, so I can enjoy secure log shipping from s2 to becky.ts.fm.

See Also




Ban Specific IP Manually with fail2ban

fail2ban

Now that I’m monitoring my logs using cetralised RSyslog, I regularly notice SSH attacks right when and as they happen. When it becomes obvious that someone’s trying to brute-force SSH, I don’t always wait to let fail2ban fix the issue – sometimes I ban the offending IP myself.

How To Ban Specific IP with fail2ban

Assuming a standard install, we’ll use the fail2ban-client command to notify sshd jail module to ban a specific IP.

Here’s how it works:

root@s1:/etc/fail2ban # fail2ban-client -vvv set sshd banip 202.70.66.228
30 7F0B121F6640 fail2ban.configreader     INFO  Loading configs for fail2ban under /etc/fail2ban
30 7F0B121F6640 fail2ban.configreader     DEBUG Reading configs for fail2ban under /etc/fail2ban
31 7F0B121F6640 fail2ban.configreader     DEBUG Reading config files: /etc/fail2ban/fail2ban.conf
31 7F0B121F6640 fail2ban.configparserinc  INFO    Loading files: ['/etc/fail2ban/fail2ban.conf']
31 7F0B121F6640 fail2ban.configparserinc  TRACE     Reading file: /etc/fail2ban/fail2ban.conf
31 7F0B121F6640 fail2ban.configparserinc  INFO    Loading files: ['/etc/fail2ban/fail2ban.conf']
31 7F0B121F6640 fail2ban.configparserinc  TRACE     Shared file: /etc/fail2ban/fail2ban.conf
32 7F0B121F6640 fail2ban                  INFO  Using socket file /var/run/fail2ban/fail2ban.sock
32 7F0B121F6640 fail2ban                  INFO  Using pid file /var/run/fail2ban/fail2ban.pid, [INFO] logging to SYSLOG
32 7F0B121F6640 fail2ban                  HEAVY CMD: ['set', 'sshd', 'banip', '202.70.66.228']
48 7F0B121F6640 fail2ban                  HEAVY OK : 1
48 7F0B121F6640 fail2ban.beautifier       HEAVY Beautify 1 with ['set', 'sshd', 'banip', '202.70.66.228']
1
48 7F0B121F6640 fail2ban                  DEBUG Exit with code 0 

Once you become comfortable, you can omit the -vvv option and skip all this verbose output:

root@s1:/etc/fail2ban # fail2ban-client set sshd banip 202.70.66.229
1

That’s it for today! Have fun!

See Also




git push Asks for Username and Password

I’ve been refreshing my gleb.reys.net website recently and experienced a weird error: pushing latest changes to GitHub resulted in my username and password prompted. Figured I should write down what the issue was and how easy it was to fix it.

git Repo Asks for Username/Password

greys@mcfly:~/proj/gleb.reys.net $ git push
Username for ‘https://github.com’: greys
Password for ‘https://[email protected]’:
remote: Invalid username or password.
fatal: Authentication failed for ‘https://github.com/greys/greys.github.io/’
greys@mcfly:~/proj/gleb.reys.net $ git remote
origin
greys@mcfly:~/proj/gleb.reys.net $ git remote show
origin
greys@mcfly:~/proj/gleb.reys.net $ git remote -v
origin https://github.com/greys/greys.github.io (fetch)
origin https://github.com/greys/greys.github.io (push)

At first I couldn’t see it

Update The Origin in git Repository

greys@mcfly:~/proj/gleb.reys.net $ git remote rm origin
greys@mcfly:~/proj/gleb.reys.net $ git remote -v

greys@mcfly:~/proj/gleb.reys.net $ git remote add origin [email protected]:greys/greys.github.io.git
greys@mcfly:~/proj/gleb.reys.net $ git remote -v
origin [email protected]:greys/greys.github.io.git (fetch)
origin [email protected]:greys/greys.github.io.git (push)

Push (with set-upstream)

greys@mcfly:~/proj/gleb.reys.net $ git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin master

greys@mcfly:~/proj/gleb.reys.net $ git push –set-upstream origin master
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 568 bytes | 568.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To github.com:greys/greys.github.io.git
018a8c0..e4f79d4 master -> master
Branch ‘master’ set up to track remote branch ‘master’ from ‘origin’.

That’s it! I’m using Netlify for automatic build and hosting of my Jekyll website, so a minute or two after the git push shown above the website got refreshed to the latest version. Nice!

See Also




Log fail2ban Messages to Syslog

fail2ban logging into syslog

With quite a few servers accepting SSH connections and protecting themselves using fail2ban, you very quickly recognize one thing: it makes a lot of sense to centralize fail2ban reporting using syslog.

To update fail2ban logging. you need to edit the /etc/fail2ban/fail2ban.conf file and replace this:

logtarget /var/log/fail2ban.log

with this:

logtarget = SYSLOG

Here’s how my section looks when I’m editing a file with vim:

Switching fail2ban log target to SYSLOG

Restart fail2ban service and enjoy:

root@s7:/var/log # systemctl reload fail2ban

See Also




Removed DHCP Daemons in Raspbian

Raspberry Pi 4

I got one of my Raspberry Pi servers attempting to obtain DHCP IP address, a behavior that ignored my static IP address configuration.

Not sure why, but it appeared I’d be getting an extra DHCP address, from the same network segment, in addition to the static IP the Raspberry Pi already had.

Normally I’d just disable the service, but since my home office network is fairly static, I figured I would just remove the DHCP package.

WARNING: do not follow my steps unless you’re in the same situation and pretty sure you’re using static IP addressing.

Double Check that You’re Using Static IP

Check your /etc/network/interfaces file, it should have something similar for your primary interface – in wired network cable case it’s eth0:

auto eth0
iface eth0 inet static
    address 192.168.1.99
    netmask 255.255.255.0
    gateway 192.168.1.1

Also, run ip a and make sure you’re seeing this same IP among the active interfaces:

greys@s7:~ $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:ee:66:88:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.99/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Remove ISC DHCP Client

So I did this:

root@srv:~# apt-get remove isc-dhcp-client
 Reading package lists… Done
 Building dependency tree
 Reading state information… Done
 The following packages were automatically installed and are no longer required:
   libdns-export1104 libisc-export1100
 Use 'apt autoremove' to remove them.
 The following additional packages will be installed:
   dhcpcd5
 Suggested packages:
   dhcpcd-gtk
 The following packages will be REMOVED:
   isc-dhcp-client
 The following NEW packages will be installed:
   dhcpcd5
 0 upgraded, 1 newly installed, 1 to remove and 207 not upgraded.

All cool? Not really. If you read carefully, you’ll notice that I removed isc-dhcp-client, but automatically installed dhcpcd5 – which started making DHCP requests again.

Remove DHCPcD5

Next step then! Let’s remove DHCPcD5:

root@srv:~# apt-get remove dhcpcd5
 Reading package lists… Done
 Building dependency tree
 Reading state information… Done
 The following additional packages will be installed:
   isc-dhcp-client
 Suggested packages:
   avahi-autoipd isc-dhcp-client-ddns
 The following packages will be REMOVED:
   dhcpcd5
 The following NEW packages will be installed:
   isc-dhcp-client
 0 upgraded, 1 newly installed, 1 to remove and 207 not upgraded.

Much better!

Or is it? If you look closer, you’ll see that this command installed isc-dhcp-client back.

Delete both DHCP Client Packages

This time I specified both packages to be removed. I even used apt-get purge instead of apt-get remove – to definitely destroy any configs:

root@srv:~# apt-get purge dhcpcd5 isc-dhcp-client
 Reading package lists… Done
 Building dependency tree
 Reading state information… Done
 The following packages were automatically installed and are no longer required:
   libdns-export1104 libisc-export1100
 Use 'apt autoremove' to remove them.
 The following additional packages will be installed:
   pump
 The following packages will be REMOVED:
   dhcpcd5* isc-dhcp-client*
 The following NEW packages will be installed:
   pump
 0 upgraded, 1 newly installed, 2 to remove and 207 not upgraded.

When this installed pump (that’s apparently another BOOTP/DHCP client – I never even heard about it before), I got curious.

Having researched online, it appears one can configure static IP in Raspberry Pi using DHCP client configs. Doesn’t sound right to me! There’s also the systemd way to disable dhcpd.service, but at this stage I was not looking for half measures.

Having carefully considered this, I decided to unstall the whole lot. It also removed wicd* (Wired and Wireless Network Connection Manager) bunch which is another set of packages for managing network interfaces and connections.

I’m honestly suprised and seriously suprised how involved a network interface and IP address configuration is! Since I’m not using any of these niceties and because this is a static server-like environment where I’m not switching Wi-Fi networks or changing connection profiles all the time, I’m comfortable letting it all go.

Uninstalling DHPCP clients, pump and Wicd

WARNING: be super sure you’re using static IP addressing on your Raspberry Pi system before running the next command.

Here’s the final uninstall command:

root@s7:~# apt-get remove dhcpcd5 isc-dhcp-client pump
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package 'isc-dhcp-client' is not installed, so not removed
Package 'pump' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  libdns-export1104 libisc-export1100 openresolv python-wicd
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  dhcpcd5 wicd wicd-daemon wicd-gtk
0 upgraded, 0 newly installed, 4 to remove and 207 not upgraded.

FINALLY! No more DHCP requests from this server 🙂

pS: on a somewhat relevant note, think I’ll upgrade all them 207 packages – but first will complete a reboot to check network configuration still works for the static IP.

See Also




Using grc (Generic Colouriser) for RSyslog

Colorized output for RSyslog files

I started updating my Centralised RSyslog server on Raspberry Pi the other day, and one of the things I’ve been meaning to research was syntax highlighting for RSyslog logs. After a brief search online, I found grc: a great tool for seeing output of many common Unix commands and log files in a completely new, colorful and useful way.

Install grc in Raspbian (Debian/Ubuntu)

I did this in Raspbian OS:

$ sudo apt-get install grc

It brought quote a few dependencies with it, but installed fairly quickly.

grc for looking at RSyslog output

Simply run grc and tail the messages file or RSyslog file. It will look like this:

RSyslog output with grc colouriser

Looking and process listing with ps and grc

Many common commands are used, but I’ll show just the ps command highlighting for now:

ps output with colorized syntax

That’s it for today. I think this is a must-have command line tool – am really impressed!

See Also




How To: Use Filesystem Labels in /etc/fstab

Filesystem label in /etc/fstab

Yesterday I have shown how to manage ext2/ext3/ext4 filesystem labels using e2label command. Continuing this topic, let’s update /etc/fstab file on my Ubuntu VM.

WARNING: don’t do this on a real server! try on a non-important virtual machine first, just to learn how to use commands, update fstab and so on. I’m using root filesystem (/) just because that’s the only filesystem I have on my Ubuntu VM.

Here’s how my /etc/fstab looks right now:

root@ubuntu:~ # cat /etc/fstab
# /etc/fstab: static file system information.
# 
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#           
# / was on /dev/sda1 during installation
UUID=ef0ca1f8-28cf-4baf-ada6-f2271aaece17 /               ext4    errors=remount-ro 0       1

Check filesystem label for / filesystem

If we run df -h command, we can see what device the root (/) filesystem is using:

root@ubuntu:~ # df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            964M     0  964M   0% /dev
tmpfs           199M  1.5M  197M   1% /run
/dev/sda1        63G  8.7G   51G  15% /
tmpfs           991M     0  991M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           991M     0  991M   0% /sys/fs/cgroup

Let’s use e2label to confirm label for /dev/sda1:

root@ubuntu:~ # e2label /dev/sda1
rootdisk

Perfect! Now that we know /dev/sda1 has label of “rootdisk“, let’s use this label to mount this filesystem going forward.

Update /etc/fstab to use filesystem labels

Editing the /etc/fstab file, comment out the UUID line for / filesystem (note the # at the start of the line now):

# UUID=ef0ca1f8-28cf-4baf-ada6-f2271aaece17 /               ext4    errors=remount-ro 0       1

and replace it with this:

LABEL=rootdisk    /               ext4    errors=remount-ro 0       1

Just to be sure things work as expected, let’s remount the filesystem rather than reboot the server:

root@ubuntu:~ # mount -o remount /

If you don’t get any errors back – this is working as expected.

See Also