2017년 3월 11일 토요일

Generate /etc/shadow PW hash from the cli using python2 and 3

In /etc/shadow, hashed and salted passwords are stored together with the user name as follows:

myuser:$6[someSaltedHash]:...

where the number following the $ can take the values 1~6 corresponding to the following hash algorithms:

1    md5
2a   Blowfish
2y   Blowfish with correct 8-bit char handling
5    sha-256
6    sha-512

Many How-to's on the Internet recommend using mkpasswd from the expect package, but I find it is much easier to use python2 or python3 to generate the salted hash.

Python 2:

python -c 'import crypt,getpass; print crypt.crypt(getpass.getpass())'

You will then be prompted to enter your plaintext password after which a /etc/shadow compatible hash will be output.


Python 3:

python3 -c 'import crypt; print(crypt.crypt("yourpw", crypt.mksalt(crypt.METHOD_SHA512)))'

In this snippet, you simply enter your plaintext password as an argument and then a /etc/shadow compatible hash will be printed out on the terminal.

You can copy-paste this salted hash into a Kickstart (RHEL and variants) or DI preseed file (Debian and variants) for automated installations.


References:

https://access.redhat.com/solutions/221403 (requires registration)

http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-password-for-shadow

2017년 2월 25일 토요일

Using ibus in non-GTK/QT apps like Emacs, Java, and Enlightenment/EFL

ibus is a popular Input Method Editor (IME) for Linux which I use for entering Korean and Chinese characters (via ibus-hangul). ibus has good compatibility with apps using the GTK or QT UI frameworks, but ibus sometimes behaves strangely in GUI apps that don't use these frameworks. For example, in Emacs, OmegaT (which uses OpenJDK 7 or 8) and Terminology (a nice terminal that uses the Enlightenment Foundation Libraries), every time I press SPACEBAR after a word, the SPACE character is inserted to the left of the last character. In other words:

"가나다 "

appears as

"가나 다"

To avoid this issue in non-GTK/QT apps on Linux, I launch the ibus daemon as follows:

env IBUS_ENABLE_SYNC_MODE=0 ibus-daemon -rdx

You can read an explanation of the ibus-daemon option flags in a previous post from my blog.

Brandon Schaefer @ Canonical, explains why this error occurs:

The problem seems to be that when IBUS_ENABLE_SYNC_MODE is enabled it pushes all the events through the im engine (such as ibus-hangul) and since it normally only handles Korean text it doesn't know what to do when, say a space is sent through, so it says it didn't handle that space event which then IBus handles it and commits that space BEFORE the preedit.

In addition, my .bashrc contains the following ibus settings:

##### ibus IME settings #####
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
export CLUTTER_IM_MODULE=ibus
export ECORE_IMF_MODULE=xim

ECORE_IMF_MODULE setting is for Enlightenment apps like Terminology terminal.

Once the ibus environment variables are properly set and ibus-daemon is launched with the appropriate options, you will be able to enter Korean and other Asian text into non-QT/GTK apps with ibus.

References:
https://github.com/ibus/ibus/issues/1847

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/880876

2017년 2월 2일 목요일

Fix black screen in tty mode with Ubuntu 16.04.1 on ASUS Prime Z270-K with KabyLake CPU

After installing Ubuntu 16.04.1 LTS via USB in UEFI mode, I rebooted and was met by a black screen. From another machine on the local network, I was able to ssh into the newly-installed Ubuntu 16.04.1 box and noticed the following in dmesg:

[  +0.000000] Call Trace:
[  +0.000002]  [] dump_stack+0x63/0x90
[  +0.000001]  [] warn_slowpath_common+0x82/0xc0
[  +0.000001]  [] warn_slowpath_fmt+0x5c/0x80
[  +0.000014]  [] __unclaimed_reg_debug+0x80/0x90 [i915_bpo]
[  +0.000012]  [] gen9_read32+0x35e/0x390 [i915_bpo]
[  +0.000002]  [] ? __pm_runtime_resume+0x5b/0x70
[  +0.000016]  [] intel_digital_port_connected+0xf8/0x290 [i915_bpo]
[  +0.000013]  [] ? intel_display_power_get+0x3b/0x50 [i915_bpo]
[  +0.000015]  [] intel_hdmi_detect+0x4b/0x140 [i915_bpo]
[  +0.000003]  [] drm_helper_probe_single_connector_modes_merge_bits+0x235/0x4d0 [drm_kms_helper]

Google reveals many similar issues with i915 Kernel Mode Setting for Intel integrated video on newer intel CPU's (Skylake and beyond).

At the GRUB menu after rebooting, I added the kernel boot parameter nomodeset and booted with F10 after which I was able to boot to a visible login prompt now that Linux is no longer trying to automatically set the video resolution.

To make the kernel boot parameter changes permanent in GRUB menu, I had to edit /etc/default/grub and edited the following:

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

I then ran sudo update-grub to update /boot/grub/grub.cfg

Some other hardware info:

$ lscpu
...
Model name:            Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz

$ dmidecode -t 2
...
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: PRIME Z270-K
Version: Rev X.0x


References:

http://askubuntu.com/questions/38780/how-do-i-set-nomodeset-after-ive-already-installed-ubuntu/38782#38782

2017년 1월 21일 토요일

Migrate from cinder loopback device to physical block device on RDO Mitaka

In PoC or test installations of RDO Mitaka via Packstack, by default the cinder-volumes LVM volume group is created in the form of a loopback file/device under /var/lib/cinder/

This might be OK for light testing, but if you plan to use cinder volumes in production you need to create the cinder-volumes VG on a real physical device.

After stopping all openstack services with openstack-service stop I used vgs and lvs to take a look at the LVM volume groups and logical volumes on my Openstack storage node (which I separated from the control node using unsupported config options in my Packstack answer file).

Despite stopping Openstack services, when I tried to use lvchange -ay and vgchange -ay to deactivate LV's in the cinder-volumes VG I kept getting error messages that some logical volumes in the VG were still active.

I finally just used gdisk to delete the problematic LVM partition housing cinder-volumes, rebooted and then created a new cinder-volumes VG as detailed in my previous post about setting up Cinder to use a physical block device.

However, after restarting Openstack services, openstack-cinder-volume.service failed to start. I examined the systemd service file for cinder-volume.service in /usr/lib/systemd/system/ and noticed that it contained the line

After = openstack-losetup.service

It turns out that /usr/lib/systemd/system/openstack-losetup.service sets up a loop device to act as a "disk" for storing the cinder-volumes Volume Group. Of course the loop device is just a file and has really bad I/O, so it should only be used for test setups.

I therefore deleted openstack-losetup.service, removed the ...losetup line from the systemd config for cinder-volume.service, and then executed systemctl daemon-reload to reload all systemd service files.

Now openstack-cinder-volume.service starts without any errors and doesn't require a loopback device.