I blogged about Generic Colouriser (grc) last week, cause I’m using it now to monitor syslog messages in my centralised RSyslog setup. I also mentioned that grc suppors many standard commands in addition to parsing common types of log files.
Colorized ls Output
Many Linux distros and even macOS support colorized file listing of the ls command, etc. Here’s how it usually looks:
Colorized ls Output with grc
Compare above example to how grc colorizes the same list of files:
Colorized ls with grc
Obviously, focus is on file permissions and ownership info.
I really like this, must be of great use for those of us just getting familiar with file/directory permissions in Unix/Linux.
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:
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.
I noticed that this server hasn’t been terribly available since upgrade to Ubuntu 19.04: more than once I went looking for the server and it was offline.
Now that I’m finally progressing with centralized RSyslog setup at home, I noticed that the UniFi controller server was reporting the following in logs recently:
So, it appears the power management has improved enough to start bringing this server to sleep every hour or so.
Since this is a recent enough version of Ubuntu, I figured there should be a way to disable power management using systemctl. Turns out, there is.
Confirm Sleep Status with systemd
IMPORTANT: I didn’t run this command on server, so this is example from another system: I’m running it on my XPS laptop with Ubuntu, just to show you expected output.
root@server:/ # sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
Created symlink /etc/systemd/system/sleep.target → /dev/null.
Created symlink /etc/systemd/system/suspend.target → /dev/null.
Created symlink /etc/systemd/system/hibernate.target → /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.
root@server:/etc/pm/sleep.d#
This is obviously a very simple way of disabling power management, but I like it because it’s standard and logical enough – there’s no need to edit config files or create cronjobs manually controlling sleep functionality.
The service is dead, no power management is happening and most importantly, my server has been up for 12 hours now.
greys@server:~$ systemctl status sleep.target
● sleep.target
Loaded: masked (Reason: Unit sleep.target is masked.)
Active: inactive (dead)
(re) Enabling Sleep in Ubuntu with systemctl
When the time comes and I would like to re-enable power management and sleep/hibernation, this will be the command I’ll run:
I have just started deploying my new VPS server online: vps1.unixtutorial.org
The idea is that I’ll be hosting a number of VPS servers for us you learn Linux basics. vps1 is Ubuntu, future VPS servers will probably be CentOS and Amazon Linux 2 (hosted on AWS). All of these will be accessible on SSH (probably non-standard port) with shell access.
vps1.unixtutorial.org specs
Location: Paris, Scaleway datacentre
OS version: Ubuntu Bionic 18.04.2 LTS
CPU: 2 vCPUs @ 2Ghz
RAM: 2GB
Disk: 20GB SSD (16GB available)
Here’s how it looks:
SSH login to vps1 server
Basic Unix Tutorial VPS rules
you get standard user access with Bash shell
no root access, but sudo can be provided for specific commands
no Internet access (you can log in and run local commands, but can’t download or upload anything from VPS server). no port forwarding .
zero tolerance policy for hacking/exploit testing – if I notice any of you trying something like this, access will be revoked
limited resource usage – please don’t leave tasks running in background, etc.
Access to Unix Tutorial VPS servers
VPS access is completely FREE, but you need to become a Patreon for Unix Tutorial supporter or member of my Unix Tutorial group on Facebook. Please get in touch with me either via group or Patreon page regarding your username setup:
preferred username (mine is greys)
your full name (will be visible to other users of the VPS server)
your email (so that I can email you the initial password)
Getting Help and Learning More
If you need guidance or mentorship with learning Linux, I provide some of this on the Active Learner membership level. If you want even more support or need specific lab setup learning a particular skill – this is possible with the Club Member level on Patreon.
Pretty cool! Didn’t realise this, but Sublime Text 3 is available for Linux as well! Today I took a few minutes to download/install it and to even make it use some of the GUI themes for better coding experience.
All of these steps are taken from the Sublime Text 3 website.
Step 1: Activate Sublime Text 3 repo
First, we install the key to trust Sublime Text 3 repo:
greys@xps:~ $ wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
[sudo] password for greys:
OK
Now we ensure apt-get will support https protocol for working with repos:
greys@xps~ $ echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list
Step 2: Install Sublime Text 3
We refresh apt package info:
$ sudo apt-get update
and install the packages:
greys@xps:~/proj/unixtutorial/examples $ sudo apt-get install sublime-text
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
dkms libgsoap-2.8.75 libvncserver1
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed
sublime-text
0 to upgrade, 1 to newly install, 0 to remove and 73 not to upgrade.
Need to get 9,835 kB of archives.
After this operation, 34.8 MB of additional disk space will be used.
Get:1 https://download.sublimetext.com apt/stable/ sublime-text 3211 [9,835 kB]
Fetched 9,835 kB in 8s (1,189 kB/s)
Selecting previously unselected package sublime-text.
(Reading database … 271734 files and directories currently installed.)
Preparing to unpack …/sublime-text_3211_amd64.deb …
Unpacking sublime-text (3211) …
Setting up sublime-text (3211) …
Processing triggers for desktop-file-utils (0.24-1ubuntu1) …
Processing triggers for mime-support (3.63ubuntu1) …
Processing triggers for hicolor-icon-theme (0.17-2) …
Processing triggers for gnome-menus (3.32.0-1ubuntu1) …
That’s it! Sublime Text 3 is now installed and can be started using the subl command:
Sublime Text 3
My primary environment is macOS, but it’s comforting to know that I can fall back on Dell XPS laptop with Ubuntu to edit some Ansible playbooks in a similar way.
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.
Have heard and possibly even tried it before, wasn’t impressed. But this time I’m doing Ansible playbooks and some light Python scripting development – and Sublime Text 3 is really growing on me.
Will be updating this post in the future, to list my settings and document plugins I decided to use.
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:
