Experimenting with Archlinux on Legacy Bios system

nano /etc/wpa_suppplicant/wpa_supplicant.conf
   ctrl_interface=/run/wpa_supplicant
   update_config=1

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

wpa_cli
   scan
   add_network
   set_network 0 ssid "home_net"
   set_network 0 psk "passphrase"
   enable_network 0
   save_config

dhcpcd wlan0

mkswap /dev/sd#
swapon /dev/sd#
mkfs.ext4 /dev/sd*
mkfs.ext4 /dev/sd*

mount /dev/sd* /mnt
mount /dev/sd* /mnt/home
mount /dev/sd^ /mnt/boot

pacstrap /mnt base
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt

ln -sf /usr/share/zoneinfo/Region/City /etc/localtime
timedatectl set-local-rtc 1

nano /etc/locale.gen
locale-gen
nano /etc/locale.conf
   LANG=en_SG.UTF-8
nano /etc/vconsole.conf
   KEYMAP=us-eng
nano /etc/hostname
   archlinux
nano /etc/hosts
   127.0.0.1 localhost.localdomain 
   :1 localhost.localdomain
   127.0.1.1 archlinux.localdomain

passwd

pacman -S grub grub-install --target=i386-pc --debug --force /dev/sda^
chattr +i /boot/grub/i386-pc/core.img

pacman -S linux
grub-mkconfig -o /boot/grub/grub.cfg

pacman -S wpa_supplicant

nano /etc/wpa_supplicant/wpa_supplicant.conf
   ctrl_interface=/run/wpa_supplicant
   update_config=1
   country=SG

useradd -m $USER
passwd $USER
usermod -aG wheel $USER

pacman -S sudo
visudo
   'uncomment wheel'

nano .config/lxqt/session.conf
   [Keyboard]
   numlock=true

pacman -S lxqt
pacman -S xorg-server
pacman -S openbox obconf xterm qt5-base mesa xorg-xinit ttf-dejavu xorg-utils xorg-twm xorg-xclock
pacman -S xf86-video-fbdev xf86-input-keyboard xf86-input-mouse
pacman -S xorg-apps linux-headers
pacman -S connman liblxqt qt5-svg cmake git qt5-tools lxqt-build-tools
pacman -S cmst
#pacman -S lxqt-connman-applet

pacman -S sddm
nano /etc/sddm.conf.d/autologin.conf
   [Autologin]
   User=$USER
   Session=lxqt.desktop

nano /etc/sddm.conf.d/avatar.conf
   [Theme]
   FacesDir=/home/$USER/pictures/self.face.icon

setfacl -m u:sddm:x ~/pictures/
setfacl -m u:sddm:r ~/pictures/.face.icon

pacman -S xscreensaver-arch-logo
pacman -S xdg-utils

nano .xinitrc
   exec startlxqt

pacman -S intel-ucode
pacman -S iucode-tool
exit
umount -R /mnt

sudo systemctl start sddm
sudo systemctl enable --now sddm
startx
sudo pacman -S tmux tree ibus ibus-libpinyin

Follow my blog with Bloglovin

Installing sshguard 2.4.0 on Fedora 30 using GNU Stow

Install GNU Stow to keep track of built-from-source-code applications using system default repository:

sudo dnf install stow

We install the following dependencies required for building sshguard application:

sudo dnf install byacc flex gcc make

We proceed to download sshguard 2.4.0 from sourceforge.net.

We can then extract to default home location /home/username.

Using terminal/console, set the location to the extracted folder using cd command:

cd sshguard-2.4.0/

We proceed to build the sshguard using source makefile by running configure  with installation location set at /usr/local/stow/sshguard and make command:

./configure --prefix=/usr/local/stow/sshguard

make

We proceed to install the sshguard application using make install command:

We edit the sshguard configuration file by setting backend executable file location at:

BACKEND="/usr/local/libexec/sshg-fw-firewalld"

We proceed to symlink the respective folders under /usr/local/stow/sshguard to various locations under /usr/local/ directory:

cd /usr/local/stow/

sudo stow sshguard

We have to ensure that the service file at sshguard.service has the following ExecStart location:

ExecStart=/usr/local/sbin/sshguard

When we make changes to SystemD service file, we need to run the following:

sudo systemctl daemon-reload

sudo systemctl restart sshguard.service

One final check is to ensure the sshguard application is running, we run the following:

systemctl status sshguard.service | less

For further reference on configuring sshguard with firewalld you may refer to the Ctrl blog article titled How to protect SSH remote login in Fedora with SSHGuard and FirewallD by Daniel Aleksandersen.

Follow my blog with Bloglovin

Configuring Edgerouter X: Part 1

Setting up ssh restricted access to Edgerouter

Introduction to Edgerouter's EdgeOS commands

Running '?' shows commands available on EdgeOS in operational (upon logging in) and configuration mode ('configure' command)

Running 'configure' allows us to go into configure mode

Running 'commit' allows us to commit changes 

Running 'commit-confirm' allows the change to take effect before reboot (important if you are unsure of the changes made and the impact to the system)

Running 'save' allows us to save the change to persistent boot configuration

Creating ssh key

ssh-keygen

Setting permission on .ssh and its subfolders

chown -R username:usergroup .ssh/

Upload ssh key

ssh-copy-id -i ~/.ssh/clienthost.pub username@routerhostname

Loadkey 

configure

loadkey 

commit

save

Limit ssh to listen to one address

set service ssh listen-address 192.168.0.1

 

Follow my blog with Bloglovin

3 Steps to Universal Grub Protection

In this instance we are using Parrot Security OS as the main OS for installing and updating grub bootloader.

The main reference of this article is based on 'Grub2/Passwords'.

First we run grub-mkpasswd-pbkdf2 by encrypting password for grub

Next we add "superusers" and "password-pbkdf2" to /etc/grub.d/00_header.

Finally, we run update-grub.

Follow my blog with Bloglovin

Introduction to Solus on a Legacy Bios Machine

GNU/Linux Distro In Reference: Solus 3.99

Solus is a unique GNU/Linux OS. It seems to be independent of any popular distributions. Today, i will share what i have observed in my first month of using Solus 3.99.  Please note my reference is on a non-UEFI Samsung RF410 machine.

1st) Responsiveness

My comment on Solus : It is fast relative to Fedora or Debian distro on a same device. I am using Cinnamon DE on Fedora and Mate DE on Parrot Security. For Solus, i also set it as Mate DE which i have used it previously on LMDE 2.

2nd) Unique package system

It is using eopkg package system. The term 'eopkg' is derived from its historical beginning as "Evolve OS", hence we can surmise that 'eopkg' is an acronym for 'Evolve OS Package' system.

Below is a few commands for handling eopkg system and it is pretty catchy as you need not key in the full command for certain keywords.

'Install':
sudo eopkg install <packagename>
or
sudo eopkg it <packagename>

'Upgrade System':
sudo eopkg upgrade
or
sudo eopkg up

'List installed packages':
sudo eopkg list-installed
or
sudo eopkg li

'rebuild eopkg databases after connection interupt':
 sudo eopkg rebuild-db
or
sudo eopkg rdb

'clean up cache after downloads in CLI':
sudo eopkg delete-cache
or
sudo eopkg dc

3rd) No '/etc/modprobe' directory

People who are acquainted with other GNU/Linux distros will find it unique again for its lack of modprobe and modprobe-related directory. How can we blacklist modules?

In Solus, we blacklist modules inside the /usr/lib64/modprobe.d/dist-blacklist.conf.  It works as it is like we do in Debian inside the /etc/modprobe.d/blacklist.conf.

4th) Update Grub using Clear Boot Manager

Solus adapts ClearOS boot manager. So when performing update on grub, we run
'sudo clr-boot-manager update' much as we run 'sudo update-grub' in Ubuntu, Debian or
'sudo grub2-mkconfig -o /boot/grub2/grub.cfg' in Fedora.

5th) Editing Kernel Commandline

In Debian, Ubuntu or Fedora, we usually edit grub configuration at /etc/default/grub by adding or removing options at GRUB_CMDLINE_LINUX_DEFAULT. In Solus, we add in options in /etc/kernel/cmdline .

For e.g.  to remove the "quiet splash" option , we add in "ignore_loglevel systemd.show_status=true splash=silent"

Summary

In summary, Solus works in a different manner and it takes a (fair) bit of learning to understand how it works in comparison to other mainstream GNU/Linux distros. Ahoy Captain!

Follow my blog with Bloglovin

Use FWTS (firmware test suite) for ACPI Component Architecture diagnosis

My purpose for this snippet is to review the FWTS for diagnosing the ACPI error log during systemd bootup. ACPI is a complex system, what i had given here is really entry level to explore the firmware test suite on Ubuntu 16.04 LTS on my Lenovo T400 laptop. Hopefully you can venture even further than i do. Ahoy!

less /sys/module/acpi/parameters/aml_debug_output

if '0' then debug output is off. We can write '1' as a parameter to enable debug output

less /sys/module/acpi/parameters/acpica_version

The output shows the acpica version in use by the OS.

sudo fwts oops acpiinfo fadt madt rsdp -f -r apic.log -D | dialog --gauge "FWTS" 10 90

This runs the 'acpiinfo' 'fadt' 'madt' 'rsdp' test of the fwts suite. The "dialog" command allows you to visually see the processing of the "fwts" command

The acpidump command allows you to get the dump the debug output of acpi for analysis using "acpixtract" command as shown in the following.

sudo acpidump -o acpi_dump

acpixtract -l acpi_dump.dat

There is more to explore as can be seen from the information in manpages of acpidump and acpixtract. I shall leave you to do it and hopefully debug the error

A "apic.log" report is generated for you to analyse the error appearing in the booting up of the Linux kernel based OS.

Follow my blog with Bloglovin

Use Udev rules to set Intel Chip: Turbo Boost/Scaling Governor & Max Freq

In my Parrot Security workstation, the Intel Chip overheats quite easily, so i prefer to set a lower Max Frequency and turning Turbo Boost. However, if you have tried and tested on your laptop and you want to set the highest frequency your workstation or server Intel chip is capable off, you may glean some insight from the udev rules created here.

Udevadm Info , Udevadm Control or Restart the Laptop

Sometimes we may be clueless as to how to implement udev rules accordingly to type of sysfs devices. In this blog, we will be aiming specifically at the cpu devices.

Running the below command gives you the key parameter you may insert into your udev rules for turning on or off Intel turbo boost techonology:

udevadm info -a -p /sys/devices/system/cpu 

The following is an example of what you may see in the terminal:

Udevadm info starts with the device specified by the devpath and thenwalks up the chain of parent devices. It prints for every devicefound, all possible attributes in the udev rules key format.A rule to match, can be composed by the attributes of the deviceand the attributes from one single parent device.

  looking at device '/devices/system/cpu':
    KERNEL=="cpu"
    SUBSYSTEM==""
    DRIVER==""
    ATTR{isolated}==""
    ATTR{kernel_max}=="511"
    ATTR{offline}==""
    ATTR{online}=="0-3"
    ATTR{possible}=="0-3"
    ATTR{present}=="0-3"

We then can create a udev prototype to see if it works, which is usually after a  full restart of the system. Definitely, we can also run 'udevadm monitor' and 'udevadm control --reload' to initiate the newly created rules. However, a full restart is recommended with SystemD init based GNU/Linux OS.

A prototype for the turbo boost rule is created at path /etc/udev/rules.d/ and the full path is:

/etc/udev/rules.d/83-cpu-boost.rules

Please note the number acting as a prefix for the rule. The higher number prefix means it is executed first by SystemD with a higher priority. The script content of this rule is gleaned from stackoverflow superuser forum at this link (https://superuser.com/questions/648583/howto-set-udev-rule-to-disable-intel-pstate-turbo-on-linux) which is running 2nd Gen Intel Core i processor and above employing intel_pstate. For 1st Gen Core i processor and below (dated before early 2011), which is considered old in mid 2018, the turbo boost technology employed is controlled by cpufreq as seen in this blog. In /etc/udev/rules.d/83-cpu-boost.rules, i inserted the following:

KERNEL=="cpu", ATTR{present}=="0-3", RUN+="/bin/sh -c 'echo -n 0 > /sys/devices/system/cpu/cpufreq/boost'"

It looks simple and should work given that it matches what 'udevadm info' is revealing. Further, we go into reloading the rules using the udevadm as mentioned earlier:

udevadm control --reload

To make sure the udev rules work , you may try to see if there is any output from the reload using
udevadm by running it in monitor mode:

udevadm monitor

There is alot of things to learn from udevadm, you may read through manpage of udevadm to gather more insight. Still, it is best to restart the OS to make sure udev rules stick.

Scaling Governor, Max Freq 

Using similar method as illustrated above, we can glean from the  cpu processor driver the parameters required to make the scaling governor and maximum frequency stick.

Input: udevadm info -a -p /sys/devices/system/cpu/cpuX

NB: X stands for any integer from 0 up to N-1 where N is total number of cpu cores

Output: for intel Nehalem or 1st gen intel cpu0,

 looking at device '/devices/system/cpu/cpu0':
    KERNEL=="cpu0"
    SUBSYSTEM=="cpu"
    DRIVER=="processor"

  looking at parent device '/devices/system/cpu':
    KERNELS=="cpu"
    SUBSYSTEMS==""
    DRIVERS==""
    ATTRS{isolated}==""
    ATTRS{kernel_max}=="511"
    ATTRS{offline}==""
    ATTRS{online}=="0-3"
    ATTRS{possible}=="0-3"
    ATTRS{present}=="0-3"

If you have noticed, the extended parent device output is the same as the above at path /devices/system/cpu.

Given there are 4 cores in i5 Nehalem processor, i created the rules for scaling governor using for loop at following path:

/etc/udev/rules.d/82-cpu-governor.rules

The parameters and script used is shown following:

KERNEL=="cpu[0-3]",DRIVER=="processor",RUN+="/bin/sh -c 'for i in 0 1 2 3  ; do echo -n conservative > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor ; done'"

Using the same logic, i created that for setting a lower maximum frequency during booting process to avert random shutdown issue. The path is :

/etc/udev/rules.d/81-cpu-maxfreq.rules 

Before going to set the parameters for max_freq, do double check for scaling_available_frequencies as the following cat command:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

My output shows the following and hence i select the value 1866000 in the script below:

2667000 2666000 2533000 2399000 2266000 2133000 1999000 1866000 1733000 1599000 1466000 1333000 1199000

As the governor is set prior to maxfreq, the number prefix is set in the order as such. The parameters and script for cpu-maxfreq is closely similar to cpu-governor as they share the same sysfs device path. It is shown as follows:

KERNEL=="cpu[0-3]",DRIVER=="processor",RUN+="/bin/sh -c 'for i in 0 1 2 3  ; do echo -n 1866000 > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq ; done'"

That's all for now, hopefully the above gives you insight for you to create your own udev rules to automate part of administering your GNU/Linux system.

Follow my blog with Bloglovin