32 -> 64 transition

Perhaps I was the last person on Earth who moved from 32-bit Linux to 64-bit Linux. Finally, it has happened. The reason is simple: I needed docker (which supports 64-bit only), and it’s much nicer to create 64-bit VMs with virtualbox.

Fortunately I had a separate /home partition, so the reinstall was pretty straightforward: mess with anything, but /home. Now it’s time to reinstall a few things, eg. ansible, libreoffice, jre 8, and friends.

KVM/libvirt intro

virt-install -c slackware-14.1-install-d1.iso –network network=default,model=e1000 -n vm1 –disk path=vm1.img,size=30 –ram 384
virt-install -c debian-8.3.0-amd64-CD-1.iso –network network=default,model=e1000 -n vm2 –disk path=/home/sj/vm2.img,size=30 –ram 2048

Ez így RAW image lesz a vm-hez, amit NEM tudsz snapshot-olni, csak menteni:
tar –create –sparse –file /mnt/bkp/guest1-2012-06-03.img.tar /home/sj/vm2.img

alternativa: qemu-img create 1.qcow2 100G

virsh attach-disk vm1 slackware-14.1-install-d1.iso hdc –type cdrom
virsh attach-disk vm1 “” hdc –type cdrom

virsh destroy vm1
virsh undefine vm1

virsh console vm1

virsh dumpxml vm1

$ virsh domblklist vm1 –details
Type       Device     Target     Source
————————————————
file       disk       hda        /home/sj/vm1.img
block      cdrom      hdc        –

$ qemu-img info vm1.img
image: vm1.img
file format: raw
virtual size: 30G (32212254720 bytes)
disk size: 2.0G

$ virsh snapshot-create-as vm1 vm1-snap-1 “1st snap of vm1” –diskspec hda,file=vm1.snap.1.qcow2  –disk-only –atomic

$ virsh snapshot-list vm1
Name                 Creation Time             State
————————————————————
vm1-snap-1        2016-03-31 10:38:22 +0200 disk-snapshot

My desktop

A few variables, settings, etc to describe my desktop

.exrc:

set nu
set showmode

.fluxbox/keys:

Mod1 l :ExecCommand xlock -mode blank
Mod1 t :ExecCommand xterm -vb -ls -fg ‘#cdc4a5’ -bg ‘#0e3851’
Mod4 r :ExecCommand xrandr –output VGA1 –auto –output LVDS1 –off
Mod4 m :MaximizeWindow
Control Mod1 Right :NextWorkspace
Control Mod1 Left :PrevWorkspace

.fluxbox/init:

session.screen0.rootCommand: fbsetroot -solid black
session.styleFile: /usr/share/fluxbox/styles/BlueFlux

about:config:

browser.newtab.url = about:blank

about:addons:

screengrab
saved password editor

 

setxkbmap -model pc105 -layout hu,us -option grp:alt_shift_toggle

Git tutorial #1

Initialise the repository on the remote server:

ssh git@yourserver.com
mkdir test/project1
cd test/project1
git init --bare

On the local host:

cd somedir/project1
git init
echo some text > somefile.txt
git add somefile.txt
git commit -s -m "my very 1st commit"
git remote add origin git@yourserver.com:test/project1
git push -u origin master

Clone the project on another host:

git clone git@yourserver.com:test/project1
cd project1

Based on http://thelucid.com/2008/12/02/git-setting-up-a-remote-repository-and-doing-an-initial-push/

SSH settings for your own good

Long story short: I highly recommend reading the stribika article, https://stribika.github.io/2015/01/04/secure-secure-shell.html.

Note: before deploying these settings, make sure your version of openssh supports them!

sshd_config settings:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
PasswordAuthentication no
ChallengeResponseAuthentication no
PubKeyAuthentication yes
AllowGroups ssh-user
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

ssh_config settings:

Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
    UseRoaming no
    VisualHostkey yes

Generate keys:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # make sure there is something left
mv "${HOME}/moduli" /etc/ssh/moduli

Sparse image készítése

dd if=/dev/zero of=/path/to/1.img bs=1 count=0 seek=100G
losetup /dev/loop0 /path/to/1.img
mkfs.jfs /dev/loop0
mount /dev/loop0 /tmp/uu
df -h | grep /tmp/uu

Mikor jöhet ez jól? Pl. akkor, ha csillió file-t akarsz létrehozni, de a filerendszered már kész van, és kevés rajta az inode. Az ext4 pl. a formázás (azaz az mkfs.ext4 futtatása) után már nem teszi lehetővé az inode-ok számának módosítását.

3-2-1 Backup: The Rule For Recovery

Doug Hazelman ugyanezzel a címmel írt egy cikket a fenti szabályról: http://www.networkcomputing.com/storage/3-2-1-backup-rule-recovery/108368175

A 3-2-1 szabály talán a legfontosabb az adatok biztonsága szempontjából. Röviden azt mondja, hogy egy cégnek 3 példányban kell az adatait tárolnia, 2 különböző adathordozón, amiből az egyik egy másik helyszínen van.

A cikk megemlíti a Pixar esetét, amelyik majdnem elveszítette a Toy Story 2-t egy ügyetlen parancs és a nem működő mentés miatt. A Pixar csak azért menekült meg, mert valakinek megvolt a film az otthoni pc-jén.

Aztán Ohio államban valaki hazavitte a szalagot, amivel ugyan teljesült az ‘1’, csakhogy betörttek a lakásába, és elvitték a mentést is, amin rajta volt 64000 állami alkalmazott személyes adata, pl. igazolvány számok, stb.

Az NTP Software cikke megemlíti Peter Krogh nevét, akitől származik a 3-2-1 szabály. Szerinte 2 féle ember van: akinél már tönkrement a storage, és akinél még csak fog tönkre menni.

Az email archiválás kapcsán említette valaki, hogy “üzletileg nem elfogadható a levelek összevissza tárolása, elkülönítése, local archive meg stb bohóckodás.“, meg hogy jól vannak a levelek a mail szerveren.

Ez nyilvánvalóan nem felel meg a 3-2-1 szabálynak, és bizonyára nem véletlen, hogy tőlünk nyugatabbra konkrétan jogszabály írja elő (FRCP, SOX, …), hogy mely ipari szereplőknek meddig kell archiválni a leveleiket, hogy meglegyen a compliance.

Arról nem is beszélve,hogy ha pedig majd egyszer megborul a mail szerver alatt a storage (Krogh szerint ez csak idő kérdése), akkor lesz majd ‘fun’. De nem is kell hardware hiba, annyi is elég a bajhoz, ha valaki véletlenül (vagy éppen szándékosan) töröl a levelekből.

Az email archiválás – főleg ha egy 3. fél végzi – akkor védelmet nyújthat ez ellen is.