Wednesday, 5 December 2018

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

Saturday, 1 December 2018

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

Wednesday, 25 July 2018

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

Monday, 4 June 2018

Snippet: website giving genuine VPN tips

Updated 06 June 2018

One of the objective review of vpn services around the world i found belongs to the online user called miri mir who is active on Wilders Security Forum and is active contributor to IVPN, a reasonably good vpn service provider. The link to his 2016 review is:

https://vpntesting.info/

Another objective review is attributed to the privacy guy who actively runs a blog "That One Privacy Site". The link to his review is:

https://thatoneprivacysite.net/

A third objective review belongs to "Restore Privacy" blog. The link to his review is:

https://restoreprivacy.com/

One more good read  is available at a blog called "VPN Analysis: Privacy Redefined". The link is:

https://www.vpnanalysis.com/

A fifth objective review is available at a blog titled "VPN Reviewer". The link is:

https://vpnreviewer.com/

Another review of vpn providers that provide peer-to-peer (p2p) file sharing is available here at the article titled "What Are the Best Anonymous VPN Services?" on 'torrentfreak.com' blog. It can be a good but lengthy read.
The link is below:

https://torrentfreak.com/which-vpn-services-take-your-anonymity-seriously-2014-edition-140315/

A reasonably informative blog with a variety of  reviews including one on keeping your vpn secure and working. Feel free to explore its content. The link is:

https://vpnftw.com/


FAZIT

My fazit for this review is that: there are several good vpn providers who fare consistently good in terms of security and honesty, such as
1) Mullvad
2) Expressvpn
3) AirVpn

and a few others that are popular (such as NordVpn) and not so known (such as Vpn.ac)

Hope the above snippet serve you well beyond 2018.
Follow my blog with Bloglovin

Saturday, 3 March 2018

ACPI Bios Warning bug :Length Mismatch PM1 Control Block

Once in a while we stumbled into one unknown warning message on our laptop or desktop machine and wish to know how it affects our machine (in terms of security or performance or powersave.

Today i going to dig into one bug which seems to happen to some of us running GNU/Linux operating system on legacy Bios machine:

ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32

Going to the documentation section for ACPI Component Architecture commissioned by Intel Corporation, we can see a list of documents (pdf and doc format). Intuitively, i select the pdf file under ACPICA user guide and programmer reference and search for the word 'acpi bios'.

This leads me to the page titled 'AcpiBiosWarning and ACPI_BIOS_WARNING'. There is a subtiltle stating "Print a formatted warning string for BIOS/firmware issues." It is a short page with the following functional description :

This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. It is intended to be used when the host detects a problem that is specific to the platform BIOS/firmware. The format of the output string is as follows:

ACPI Firmware Warning (ModuleName-LineNumber): <message> [ACPICA version number] 

Next on the list, we can see something substantial (1000 or so pages) : 'ACPI Specification Version 6.2'  hosted by uefi.org. In this specification, we can find in-depth information about the 'FADT' and 'PM1 Control Block'. Before we go further, let's take a look at some definition as defined that will be relevant to our discussion here:

Legacy BIOS - One form of Host Processor Boor Firmware used on x86 platforms which uses a legacy x86 BIOS structure. This form of host processor boot firmware has been or is being replaced by UEFI.

UEFI - One form of Host Processor Boot Firmware which uses a Unified Extensible Firmware Interface (UEFI) structure (as defined by the UEFI Forum). This is the current host processor boot firmware structure being adopted as a standard in the industry. This term should be used when referring specifically to UEFI code on a platform.


Operating System-directed Power Management (OSPM) - A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand.

Advanced Configuration and Power Interface (ACPI) - A method for describing hardware interfaces in terms abstract enough to allow flexible and innovative hardware implementations and concrete enough to allow shrink-wrap OS code to use such hardware interfaces.

ACPI Namespace - A hierarchical tree structure in OS-controlled memory that contains named objects. These objects may be data objects, control method objects, bus/device package objects, and so on. The OS dynamically changes the contents of the namespace at runtime by loading and/or unloading definition blocks from the ACPI Tables that reside in the ACPI system firmware. All the information in the ACPI Namespace comes from the Differentiated System Description Table (DSDT), which contains the Differentiated Definition Block, and one or more other definition blocks.

Root System Description Pointer (RSDP) - An ACPI-compatible system must provide an RSDP in the system's low address space. This structure's only purpose is to provide the physical address of the RSDT and XSDT.

Root System Description Table (RSDT) - A table with the signature 'RSDT', followed by an array of physical pointers to other system description tables. The OS locates that RSDT by following the pointer in the RSDP structure.

Extended Root System Description Table (XSDT) - The XSDT provides identical functionality to the RSDT but accommodates physical addresses of DESCRIPTION HEADERs that are larger than 32 bits. Notice that both the XSDT and the RSDT can be pointed to by the RSDP structure.

Differentiated System Description Table (DSDT) - An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system, The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it.

Secondary System Description Table (SSDT)SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.

Fixed ACPI Description Table (FADT) - A table that contains the ACPI Hardware Register Block implementation and configuration details that the OS needs to directly manage the ACPI Hardware Register Blocks, as well as the physical address of the DSDT, which contains other platform implementation and configuration details. An OEM must provide an FADT to an ACPI-compatible OS in the RSDT/XSDT. The OS always inserts the namespace information defined in the Differentiated Definition Block in the DSDT into the ACPI Namespace at system boot time, and the OS never removes it.

Section 4 ACPI HARDWARE SPECIFICATION

Under the main header 'ACPI Register Model' and the given subheader 'ACPI Register Summary' and at the table for 'PM1 Control Registers', we can see that Register 'PM1_CNTa' has Address relative to register block <PM1a_CNT_BLK>.

Under 'PM1 Control Registers', PM1a_CNT_BLK is introduced as a register block needed for the following interface purpose:
1) SCI/SMI routing control/status for power management and general-purpose events
2) Processor power state control/status
3) Global Lock related interfaces
4) System power state controls (sleeping/wake control)

It is stated that the PM1a_CNT_BLK has a PM1x_CNT with a minimum size of 2 bytes.

Further, under the main header 'Fixed Hardware Registers', and subheader 'PM1 Control Grouping' and 1 level under the subheader of title 'PM1 Control Registers':

the fixed hardware feature control bits in the PM1 control registers can be split between 2 registers, PM1a_CNT or PM1b_CNT. Each register grouping are located at a unique 32-bit aligned address, and the pointers, PM1a_CNT_BLK or PM1b_CNT_BLK, can be used to point to the respective registers. The values for these pointers to the register space are kept in the FADT.

Section 5 ACPI Software Programming Model

Under the main header 'ACPI System Description Tables' and subheader 'Fixed ACPI Description Header (FADT)':

FADT defines various fixed hardware ACPI information such as base address for the hardware register blocks such as PM1, Power Management Timer (PM_TMR) and General Purpose Event Register Blocks (GPE) ,etc.

Under the main header 'ACPI System Description Tables' and subheader 'Definition Blocks':

It is a data block in AML format and contains information about hardware implementation details in the form of AML objects that contain data, AML code or other AML objects.

Recall the definition of ACPI Namespace as it is useful in the discussion here.
OSPM "loads" or "unloads" an entire definition block as a logical unit using the AML Load() or LoadTable() operators. These operators allow a Definition Block to load other Definition Blocks, statically or dynamically, which can define new system attributes or build on prior definitions. As OSPM initializes, it loads the DSDT, which contains Differentiated Definition Block, through DSDT pointer retrieved from the FADT. In addition, OSPM will load other definition blocks in the RSDT/XSDT which contains the SSDT definitions. It is claimed that the power of the Definition Block lies in its ability to allow operations through the use of AML operators to be combined in numerous ways to provide functionality to OSPM.

Under the main headers (1)'Definition Block Encoding' and (2)'Control Methods and the ACPI Source Language (ASL)':

The missing link between ASL and the definition blocks is written here. OEM and platform firmware vendors write Definition Blocks using the ACPI Source Language (ASL) and use a translator to produce the byte stream encoding. Within the stream encoding, (1) packaging and object declarations at load-time, and (2) object reference at run-time or package contents.

Encodings of implicit length objects either have fixed length encodings or allow for nested encodings that, at some point, result in an explicit or
implicit fixed length. The first object present in a Definition Block must be a named control method (aka initialization control). Packages are objects that contain an ordered reference to one or more objects. A package can also be considered a vertex of an array, and any object contained within a package can be another package. This permits multidimensional arrays of fixed or dynamic depths and vertices. Below is an example curated from the ACPI Specification to illustrate the control method of the ASL language:

// ASL Example
DefinitionBlock (
"forbook.aml", // Output Filename
"DSDT", // Signature
0x02, // DSDT Compliance Revision
"OEM", // OEMID
"forbook", // TABLE ID
0x1000 // OEM Revision
)
{ // start of definition block
OperationRegion(\GIO, SystemIO, 0x125, 0x1)
Field(\GIO, ByteAcc, NoLock, Preserve) {
CT01, 1,
}
Scope(\_SB) // start of scope
Device(PCI0) { // start of device
PowerResource(FET0, 0, 0) { // start of pwr
Method (_ON) {
Store (Ones, CT01) // assert power
Sleep (30) // wait 30ms
}
Method (_OFF) {
Store (Zero, CT01) // assert reset#
}
Method (_STA) {
Return (CT01)
}
} // end of power
} // end of device
} // end of scope
} // end of definition block

 FWTS

Using Ubuntu FWTS tool, i run the following command to glean information for the bug:

fwts oops acpiinfo fadt -f -r apic.log -D | dialog --gauge "Firmware Test Suite" 10 90

A summary of the failures presented by the tool:

Medium failures: 7
 fadt: Both 32-bit FIRMWARE_CTRL and 64-bit X_FIRMWARE_CTRL pointers to the FACS
 are set but only one is allowed.
 fadt: FADT PM1A_EVT_BLK has both a 32-bit and a 64-bit address set; only one should be used.
 fadt: FADT PM1A_CNT_BLK field has both the 32-bit and the 64-bit field set.
 fadt: FADT PM2_CNT_BLK field has both the 32-bit and the 64-bit field set.
 fadt: FADT PM_TMR_BLK field has both the 32-bit and the 64-bit field set.
 fadt: 32 and 64 bit versions of FADT pm1_cnt size do not match (0x10 vs 0x20).
 rsdp: RSDP: only one of RsdtAddress or XsdtAddress should be non-zero.  Both fields are non-zero.


The bug seems to be a result of 32 bit version and 64 bit version of FADT_pm1_cnt size not matching up, which may only be fixed by Lenovo (indirectly using Bios Update) or Intel.


Follow my blog with Bloglovin

Wednesday, 31 January 2018

Overheating Intel Nehalem/Westmere Laptop

If you are using Intel {Nehalem} processor running Samsung motherboard, you may face overheating problem and 'catastrophic shutdown': a term which is scary and in reality, it can be. Loss of data and corrupted filesystems or (hopefully you have backed up last week) corrupted hard drive.

There maybe a easy solution such as disabling turbo boost in the Bios. (Unfortunately, Samsung RF410 doesn't have such easy solution.)

*Digression* If you are booting Windows 10, you can change the 'power options' setting to 'power saver' or 'balanced' mode. Further tweaks include going to 'change advanced power settings' > 'Processor power management':
1) set 'Maximum processor frequency' to a value such as 2000 Mhz (or any value that is lower than your maximum frequency) and,

NB: Do ensure your 'Minimum processor state' is set at 50% or higher if you are running heavy duty program.

2) under 'System cooling policy' select 'passive' for both 'On battery' and 'Plugged in'.

Great, enough for Windows, it is a small digression here to talk about it. Now we shall focus on GNU/Linux, in particular, Fedora 27.

*Lesson Proper* To turn off Turbo boost albeit a temporary solution as the Bios reset it each boot-up, we can run the following as root:

sudo -i
echo 0 > /sys/devices/system/cpu/cpufreq/boost
exit

Alternatively, we can change the Model Specific Register (msr) by:

1) installing 'msr-tools',

sudo dnf install msr-tools

2) enabling the module 'msr' editing the 'turbo' register :

sudo dnf install msr-tools
modprobe msr

3) checking the value of the register individually, a return of '1' means turbo boost disabled and '0' means turbo boost enabled using option '-p#' where #=0,.., number of core - 1:

sudo rdmsr -p0 0x1a0 -f 38:38 
sudo rdmsr -p1 0x1a0 -f 38:38
sudo rdmsr -p2 0x1a0 -f 38:38
sudo rdmsr -p3 0x1a0 -f 38:38

or collectively:

sudo rdmsr -a 0x1a0 -f 38:38

or a return of '4000850081' and '850081' respectively using the following:

sudo rdmsr -x 0x1a0


NB: you may refer the man page of rdmsr online
http://manpages.ubuntu.com/manpages/trusty/man1/rdmsr.1.html

NB: you can refer to Table 2-14 representing "MSRs in Processors Based on Intel® Microarchitecture Code Name Nehalem",  search under 'register address' the 'hex' value of '1A0H' Intel Nehalem Model-Specific Registers (MSRS) and search under 'Register Name' the decimal value of '38', you see 'Bit Description' having the string value of 'Turbo Mode Disable (R/W)' => hence '1' : Disabled; '0' : Enabled
https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf

4) editing the value of the register by pointing the register '0x1a0' to the value '0x4000850081' collectively:

sudo wrmsr -a 0x1a0 0x4000850081

 or individually disable turbo boost on the 1st and 3rd core:

sudo wrmsr -p0 0x1a0 0x4000850081
sudo wrmsr -p2 0x1a0 0x4000850081

NB: you may refer to the man page of wrmsr online
http://manpages.ubuntu.com/manpages/xenial/man1/wrmsr.1.html

5) verify the value at register '0x1a0' which should return '4000850081':

sudo rdmsr -x 0x1a0
 
6) Alternatively, we can verify the 'turbo boost' mode is disabled using 'cpupower' by installing 'cpupower' and checking using option 'cpupower-frequency-info':

sudo dnf install cpupower
cpupower -c all frequency-info

7) Another useful feature of 'cpupower'  is switching of power governor to 'conservative' mode using 'cpupower-frequency-set' option:

cpupower -c all frequency-set -g conservative

8) Alternatively editing sysfs /sys/devices/system/cpu directory:

echo conservative > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 

9) Setting up a udev rule for permanent setting of 'conservative governor:

i) creating /etc/udev/rules.d/50-scaling-governor.rules with the content:

SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+=" sudo /bin/sh -c ' echo conservative > /sys/devices/system/cpu/cpufreq/policy*/scaling_governor ' "

ii) changing /etc/udev/udev.conf from 'info' to 'debug'

udev_log="debug"

iii) creating /etc/dracut.conf.d/99-udev.conf, noting the style of the text in 'man dracut.conf'

install_optional_items+=" /etc/udev/udev.conf "

iv) update initramfs image using the following for Fedora:

sudo dracut --force

10) To verify the temperature we can use 'lm_sensors' to check the temperature by installing 'lm_sensors-sensord' and 'lm_sensors-libs' and run 'sensors':

sudo dnf install lm_sensors-sensord lm_sensors-libs
sensors 

11) Alternatively, we can check the temperature of the physical processor cores using sysfs /sys/class/thermal directory:

cat /sys/class/thermal/thermal_zone*/temp

The above is hopefully enough to trouble shoot your laptop if you are running Intel Core architecture or Intel Nehalem architecture.

For Sandy bridge and above processor, you are likely to find good company in Thermald for intel_pstate management. For more info, you can refer to the ArchWiki article on "CPU frequency scaling" which has mentioned tools like 'thermald', 'cpupower' and 'i7z'.
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Follow my blog with Bloglovin

Changing Username on Debian sysvinit or systemd

Sometimes we feel there is a need to change our username on the GNU/Linux for many different reason. It may be easy or difficult depending on your approach.

The easy way out is to boot into recovery as a 'admin priviledged' user and use 'usermod' and 'groupmod' command:

1) usermod -l newusername oldusername
2) groupmod -n newusername oldusername
3) usermod -d /home/newusername  -m newusername

The difficult way (or rather more tedious approach) is to use 'vipw' command:
1) vipw -p (replace "oldusername" with "newusername" and "/home/oldusername" with "/home/newusername")
2) vipw -s (replace "oldusername" with "newusername")
3) vigr -g (replace all entries "oldusername" with "newusername")
4) vigr -s (replace all entries "oldusername" with "newusername")




Tuesday, 23 January 2018

Fixing time on sysvinit and systemd

If you have a system that boot using different GNU/Linux init systems such as sysvinit (aka System 5) and systemd (aka System 500) in addition to proprietary Windows system, you may face incorrect time display on one of the aforementioned system. The difference in time display is dependent on the time difference of your location and the UTC time. Further complication may result from concept like Daylight Saving Time (DST).

If the Bios is set to localtime, you may fix it in systemd boot system using 'timedatectl' command like:
sudo timedatectl set-local-rtc 1

However, if you are using sysvinit and Bios is using localtime, you can set inform the system that local time is being used using 'hwclock' command like:
sudo hwclock --localtime

or to synchronize the hardware clock with system time and inform the system using:
sudo hwclock --systohc --localtime

If Bios is using UTC time, you may revert the change with 'timedatectl' like:
sudo timedatectl set-local-rtc 0

or with 'hwclock' like:

sudo hwclock --utc

or in Windows, we correct time by creating *.reg file to inform system that the hardware clock is using UTC with the following contents:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=dword:00000001


To import the contents into registry, we double click it. Should the registry edit doesn't respond to it on a x86_64 computer, we change the word 'dword' to 'qword' as follows:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=qword:00000001

Should you ever switch between Windows and Linux system, the above command shall help to correct the time change.

Follow my blog with Bloglovin

Sunday, 14 January 2018

Unifi Webgui Repair

Chances are if you run the following setup to harden the Ubiquiti Unifi setup after following instructions at Ubiquiti forum, you are likely to run into problem after each update.

The forum article to harden Unifi setup is here "Linux  Unifi Controller default Debian setup is grossly insecure:

https://community.ubnt.com/t5/UniFi-Feature-Requests/Linux-Unifi-Controller-default-Debian-setup-is-grossly-insecure/idi-p/1752863 

The steps include the following:
1) systemctl stop unifi
2) groupadd unifi
3) useradd -g unifi -s /bin/false -d /dev/null unifi
4) chown -R unifi:unifi /var/log/unifi /var/lib/unifi
5) rm -rf /var/run/unifi
6) cat > /etc/systemd/system/unifi.service.d/security.conf <<EOF
[Service]
RuntimeDirectory=unifi
User=unifi
Group=unifi
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
EOF
7) systemctl daemon-reload
8) systemctl start unifi


If you run Fail2ban, it probably shows an error and you need to edit the logpath in /etc/fail2ban/jail.local under [ubiquiti] with the 'logpath = /var/log/unifi/server.log'. The Unifi Webgui may fail to run too (but this is likely an isolated issue).
 
Error message that unifi fail to make links to default path to /usr/lib/unifi/data, /usr/lib/unifi/logs, /usr/lib/unifi/run: 

unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/data': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/data': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/logs': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/logs': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/run': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/run': No such file or directory

unifi[1726]: log4j:ERROR setFile(null,true) call failed.
unifi[1726]: java.io.FileNotFoundException: logs/server.log (No such file or directory)

Run the following commands to link the /var/*/unifi folders to /usr/lib/unifi/* folders:

sudo ln -s /var/log/unifi/ /usr/lib/unifi/logs
sudo ln -s /var/lib/unifi/ /usr/lib/unifi/data
sudo ln -s /var/run/unifi/ /usr/lib/unifi/run

The following error now appears because of the symlink made above using 'ln -s'.

unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/data': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/data': Read-only file system 
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/logs': Read-only file system
 unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/logs': Read-only file system
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/run': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/run': Read-only file system

If the Webgui is not up, it turns out that mongodb.service is not active.


Hence, run :
systemctl restart mongodb.service

If there is problem in setting up the access permissions of the folders or files: it is good to set stricter permission at the downstream level. For example, setting /usr/lib/unifi to 755 where owner has 'rwx' permission, user belongs to a group has 'rw-' permissions and other users not in the group has 'rw-' permission. On the other hand the symlink target of /usr/lib/unifi/data and /usr/lib/unifi/logs may have another set of access permissions, such as setting /var/lib/unifi and /var/log/unifi to 700 where only owner has 'rwx' permission. Going downstream, the permissions settings of /var/log/unifi/server.log may have stricter permissions of 600 where the user has only 'rw-' permissions.

NB: 'r' stands for read access, 'w' stands for write access, and 'x' stands for execute access.

Update 20 March 2018:

With the latest update to 5.7.20-10627:
There is a bug reading  " Cannot open PID file /var/run/unifi.pid ". I managed to fix it by editing  /usr/lib/unifi/bin/unifi.init, specifically changing the following line of PIDFILE:

#originally PIDFILE is directly placed directly under /var/run
#PIDFILE="/var/run/${NAME}.pid"
#now it is edited to include under another layer under ${NAME}
PIDFILE="/var/run/${NAME}/${NAME}.pid"


Follow my blog with Bloglovin

Monday, 1 January 2018

Repairing Fedora Grub using Fedora Live USB

First, Prepare the Fedora Workstation Live CD using Fedora Media Writer.

Next, run the Workstation Live CD and run the console.

Then, enter the following commands if you are running the separate boot and root partition:

1) sudo mount /dev/sdaX /mnt

Note: sdaX is the root partition

2) sudo mount /dev/sdaW /mnt/boot

Note: sdaW is the boot partition

The following files are essential for running the essential processes for repairing grub and shall be mounted:

3) sudo mount --bind /dev /mnt/dev

4) sudo mount --bind /proc /mnt/proc

5) sudo mount --bind /sys /mnt/sys

6) sudo mount --bind /var/run /mnt/var/run

Now, you are ready to go into the Fedora partitions to repair the grub files. The path should be changed to root user from liveuser> to root>:

7) sudo chroot /mnt

If you are running dual boot Windows and Fedora system, the following command will replace the Metro Interface:

8) grub2-install /dev/sda

With a dual-boot or multi-boot systems, the following command probe for operating systems installed on your harddrive:

9) grub2-mkconfig -o /boot/grub/grub.cfg

Now, we should be done with the repair and can proceed to unmount the boot and root partitions and other files.

10) exit

11) sudo umount /mnt/var/run

12) sudo umount /mnt/sys

13) sudo umount /mnt/proc

14) sudo umount /mnt/dev

15) sudo umount /mnt/boot

16) sudo umount /mnt

Finally, we can shutdown and restart to see if it is successful. Sometimes if there is any error message along the way, we need to run this process twice.


Follow my blog with Bloglovin

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 /e...