Gargamel.NU

Jag har ett par script som jag vill köra för att få information om volymgrupperna i LVM, bland annat för att uppdatera conky med information.
Problemet har varit att samtliga kommandon som har med lvm att göra kräver att root kör dem, och sudo promptar som sagt efter lösen och blir svårt att skripta med. Jag vill ju inte skriva in lösenord i skriptet.

Lösningen är sudoers filen.
för att editera i sudoers så använder du kommandot visudo

$ sudo visudo

detta för att filen /etc/sudoers måste ha speciella rättigheter (inte ens root har skrivrättigheter) och om rättigheterna inte stämmer överens så kommer sudo kommandot att sluta fungera, och du blir tvungen att boota i rescue mode för att återställa rättigheterna.

Genom att skapa ett “Command Alias” för de kommandon jag behöver i /etc/sudoers och sen sätta en sudo regel för min användare att jag inte behöver ange lösenord när jag kör dessa kommandon så har jag skapat förutsättningarna för att kunna scripta.

först in med “Command Alias”

# Cmnd alias specification
Cmnd_Alias      LVMDISPLAY = /sbin/vgs, /sbin/vgdisplay, /sbin/lvs, /sbin/lvdisplay

Cmnd_Alias är kommandot för att skapa ett “Command Alias”
LVMDISPLAY är mitt namn på mitt alias, och efter = så kommer en radda med kommaseparerade kommandon.

Sen skapar vi sudo regeln, den slängde jag in längst ner i filen

# Run lvm commands without promting for password
barre ALL=NOPASSWD: LVMDISPLAY

barre är mitt användarnamn
ALL betyder att det gäller alla maskiner, det är möjligt att specificera vilka serverar/desktops/laptops jag har rätt att köra dessa kommandon på
NOPASSWD betyder att sudo inte skall fråga efter lösen
LVMDISPLAY är det alias vi skapade.

Sen är det bara att avsluta och spara visudo och köra.

$ sudo vgs
  VG       #PV #LV #SN Attr   VSize   VFree
  vg_raid1   1   2   0 wz--n- 135.07G    0
  vg_raid5   1   2   0 wz--n-   1.73T 1.54T

Jag jobbar med datalagring och springer varje vecka på företag och organisationer som p.g.a. dåliga rutiner och ett slentrialt synsätt på backup/restore skapar sig problem som är dyra och svåra att arbeta bort. Jag får uppfattningen av att många företag inte tar sin säkerhetskopiering på allvar och ser det som ett onödigt ont. Vilket det kanske är också, säkerhetskopiering är något som vi förhoppningsvis aldrig behöver använda, men vi måste ta itu med det ändå.
Det vanligaste backup-schemat jag springer på är en G-F-S (Grand father – Father – Son) som bygger på en full-backup (father) som normalt tas en gång per vecka, mellan full-backup tas en Inkrementell backup (Son) och med jämna mellanrum, typ en gång per månad, körs en kopia på full-backup och spars off-site (grand father).
Helt slentrialt och på rutin faller samtliga system och applikationer in i detta backup-schema, dessutom samtiga volymer. Även systemdiskar och applikationsbinärer.

Så, varför klagar jag? Vad är problemet?

Det är enkel mattematik, och belysning av problemet som behövs i många fall.
Låt oss anta att jag har 130st Windows serverar som samtliga går under ett och samma G-F-S schema:

• Father:
  Full backup en gång per vecka, skall finnas i fyra generationer. Det innebär att vi som mest har fem versioner av detta jobb.
• Son:
  Inkrementell mellan full-backup, dessa spars i två veckor.
• Grand father:
  En månads kopia på sista ”father” varje månad och spars i ett år.

Detta är ett väldigt vanligt scenario och detta stöter jag på allt för ofta.
Nu gör vi några räkneexempel baserat på schemat ovan.
Jag utökar min diskyta med 100GB, och eftersom data är som gas och fyller det utrymme som finns, så har vi efter ett år utökat backupsystemet att hantera ytterligare 1.7TB. Jag har alltså minst 17 kopior på samtliga filer i mitt backupsystem, 5st Father och 12st grand father.
Varför? Behöver vi verkligen det? Förmodligen inte.

Och vänta, det är inte klart ännu. Det blir värre.
Som jag skrev tidigare i mitt exempel så hade jag 130st Windows servrar som samtliga faller in i samma lata schema, och eftersom samtliga volymer faller in i samma G-F-S strategi på samtliga servrar innebär detta att:

• Vi har minst 2 210 kopior av NOTEPAD.EXE i vår backupmiljö!!!
• Minst 4.5GB Av backupvolymen äts upp av MRT.EXE (Malicious Software Removal Tool)
• 8-10TB av backupvolymen äts upp av Windows systemfiler.

Det som irriterar mig och gör mig frustrerad är att väldigt få frågar sig varför? Är det nödvändigt att ta säkerhetskopia på samma filer gång på gång på gång på gång.
Ibland är det så, och då är det inget att prata om, ibland finns kraven på en låg RTO (Recovery time objective) vilket kräver en högre säkerhetsnivå. Men oftast finns inte behovet eller kravet, men ändå görs det.

Så det som händer är att det investeras i större, snabbare och ”tuffare” tekniker för att hantera våra dåliga backupstrategier. Vi investerar i de-duplicering, backup-2-disk och snabbare bandstationer för att måla över ett dåligt gjort grundarbete.
Jag är medveten om ”Syntetiska fullbackuper” och ”incrementel forever” tekniker som ”tar bort” problemet jag belyser här. Deduplicering är också en teknik som hjälper till att spackla över ”sprickorna” i vår strategi. Men grundproblemet finns kvar, den slentriala synen på backup/restore kvarstår….
Det spelar ingen roll hur mycket läppstift du målar på en gris, det kommer fortfarande vara en gris….

Hitachi Data Systems har gjort en “utbildningsfilm” för vad perpendicular recording tekniken på hårddiskar ger, rolig tycker jag.. men så är jag en ~nerd~ också.

Hoppas att de gör något liknande för nästa teknikrevolution för hårddiskar som “Patterned Media” eller “Thermally Assisted Recording”
Men tills dess… titta och njut ;)

Nu har HP testat och certifierat Debian 5.0 (Lenny) på HP Proliant familjen. Vilka servrar som är testade och certifierade hittar ni här

Det är är inte en fullfjädrad cerifiering, jag citerar:

“While Debian does not have an official certification program, HP has made a commercially feasible effort to test Debian on selected systems.”

Men det är ialla fall en bit på väg.

Det tråkiga med HP är att SWD på HP inte vill testa och certifiera Debian mot lagringsprodukterna, men jag håller tummarna.

Jag sitter med openbox, och har installerat thunar (som filhanterare) för att familjen har lättare att använda datorn då.

Upptäckte dock att automontering av USB-ansluten disk möttes av ett flemeddelande:

Failed to mount “2G Removable Volume”.
org.freedesktop.hal.storage.mount-removable no <– (action, result).

Efter lite googlande så hittade jag några “work around” för detta, och det var att editera /etc/PolicyKit/PolicyKit.conf. Men detta är som sagt en “work around” och inte vidare snygg en heller…

Tittar jag dessutom med polkit-auth vilka policys autheritations jag har så är det på tok för få

$ polkit-auth
org.freedesktop.hal.device-access.virt-hardware
com.ubuntu.devicedriver.info
com.ubuntu.devicedriver.check
com.ubuntu.devicedriver.update
org.freedesktop.hal.device-access.cdrom
org.libvirt.unix.monitor

Detta får mig att fundera lite…
en ck-list-sessions avslöjar att min openbox session inte finns med… konstig…

$ ck-list-sessions
Session1028:
	uid = '1000'
	realname = ''
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2009-03-22T08:19:04.761007Z'
	idle-since-hint = '2009-03-22T10:03:05.004977Z'

Så. i ~/.xinitrc (finns inte den, så skapa den) så startar vi openbox-session med ck-launch-session
Så här enmkel ser min ~/.xinitrc ut

#!/bin/bash

# ~/.xinitrc
#

exec ck-launch-session openbox-session

Eter en omstart av openbox fungerar automonteringen som den skall och så här ser ck-list-session ut

~$ ck-list-sessions
Session1028:
	uid = '1000'
	realname = ''
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2009-03-22T08:19:04.761007Z'
	idle-since-hint = '2009-03-22T11:03:05.000953Z'
Session1033:
	uid = '1000'
	realname = ''
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2009-03-22T11:02:38.945845Z'

samt att polkit-auth ser lite bättre ut

$ polkit-auth
org.freedesktop.hal.storage.mount-removable
org.freedesktop.hal.storage.eject
org.freedesktop.hal.storage.crypto-setup-removable
org.freedesktop.hal.device-access.virt-hardware
org.freedesktop.hal.lock
org.freedesktop.hal.wol.enabled
org.freedesktop.hal.wol.enable
org.freedesktop.hal.wol.supported
com.ubuntu.devicedriver.info
com.ubuntu.devicedriver.check
com.ubuntu.devicedriver.update
org.freedesktop.hal.killswitch.bluetooth
org.freedesktop.hal.killswitch.wlan
org.freedesktop.hal.killswitch.wwan
org.freedesktop.consolekit.system.stop
org.freedesktop.consolekit.system.restart
org.freedesktop.hal.device-access.sound
org.freedesktop.hal.device-access.video4linux
org.freedesktop.hal.device-access.cdrom
org.freedesktop.hal.device-access.dvb
org.freedesktop.hal.device-access.camera
org.freedesktop.hal.device-access.scanner
org.freedesktop.hal.device-access.audio-player
org.freedesktop.hal.device-access.ieee1394-iidc
org.freedesktop.hal.device-access.ieee1394-avc
org.freedesktop.hal.device-access.pda
org.freedesktop.hal.device-access.smart-card-reader
org.freedesktop.hal.power-management.shutdown
org.freedesktop.hal.power-management.reboot
org.freedesktop.hal.power-management.set-powersave
org.freedesktop.hal.power-management.suspend
org.freedesktop.hal.power-management.hibernate
org.freedesktop.hal.power-management.cpufreq
org.freedesktop.hal.power-management.lcd-panel
org.freedesktop.hal.power-management.light-sensor
org.freedesktop.hal.power-management.keyboard-backlight
org.freedesktop.hal.dockstation.undock
org.libvirt.unix.monitor

I och med version 3.4 av Openbox kan du välja om Alt+Tab för att växla mellan fönster skall ta hänsyn av alla fönster, oavsätt vilken desktop de ligger på.

Jag personligen tycker det är skönt och det är en “enkel” syntax i din rc.xml

Här är min “Window cycling bar” innan jag slog på

Det är fönstrerna på det aktiva skrivbordet.

För att slå på så ändrar du i rc.xml från:

till:

  
      yes
    
    
      yes
    

Och så här blev det då, samtliga fönster från samtliga skrivbord

Som jag skrev tidigarem,  Säkra upp sshd, så måste man distibuera den publika nyckeln till de system som man vill/ska använda certifikat för att logga in via ssh.

Det jag då skrev var ett “relativt” komplicerat sätt (eller snarare många steg) för att kopiera över den publika nyckeln

till målservern. Det finns nämnligen ett enklare sätt, med hjälp av ssh-copy-id

$ ssh-copy-id user@host

Jag såg detta i mitt mail från logwatch

--------------------- SSHD Begin ------------------------

 Illegal users from:

    82.76.35.78 (82-76-35-78.rdsnet.ro): 90 times

    213.134.125.20: 1128 times

    217.219.193.74: 2 times

  **Unmatched Entries**

 reverse mapping checking getaddrinfo for 82-76-35-78.rdsnet.ro [82.76.35.78] failed - POSSIBLE BREAK-IN ATTEMPT! : 90 time(s)

 ---------------------- SSHD End -------------------------

Det är formodligen något bot-net som letar efter svagt skyddade ssh-servrar och försöker bryta sig in med att prova logga in med svagt säkrade lösenord. Jag är inte direkt orolig att de skall lyckas eftersom jag bara tillåter certifikat-inloggning på min ssh-server.

Men, det är onödigt att överhuvudtaget tillåts att försöka 1128 gånger innan de ger upp. Därför installerar jag fail2ban som är ett program som scannar logfilerna och letar efter felaktiga inloggningsförsök och om den hittar det så skapar den en brandväggregel (iptable) som blockar addressen helt och hållet.

fail2ban supporterar olika tjänster, bland annat ssh, och default felförsök för ssh är 6 misslyckade inloggningar.

Nu ser det ut så här i logwatch istället.

 --------------------- fail2ban-messages Begin ------------------------

 Banned services with Fail2Ban:                 Bans:Unbans

    ssh:                                                    [  4:4  ]

       61.184.101.46                                           1:1

       203.231.27.211                                          1:1

       219.140.253.199                                         1:1

       220.128.174.130 (220-128-174-130.HINET-IP.hinet.net)    1:1  

 ---------------------- fail2ban-messages End -------------------------

logwatch konfigurationsfil heter logwatch.conf och ligger på tre olika ställen i filsystemet, och alla används.

Den första filen: /usr/share/logwatch/default.conf/logwatch.conf

Läses in först av logwatch och innehåller alla default-inställningar som programmet har.

Den andra filen: /usr/share/logwatch/dist.conf/logwatch.conf

Det är en “override” på första konfigurationsfilen och ställer in default värden för logwatch som gäller för denna distubition av linux (d.v.s. Ubuntu) och läses in efter /usr/share/logwatch/default.conf/logwatch.conf.

Den tredje filen: /etc/logwatch/conf/logwatch.conf

Det är en systemspecifik konfigurationsfil och läses in sist. Så alla defaultparametrar du vill ändra på gör du i denna fil, de kommer gälla oavsätt vad som står i de övriga konfigurationsfiler. Denna fil finns inte när du installerar logwatch, utan måste skapas vid behov.

Min systemspecifika konfgiurationsfil ser ut så här:

Detail = Medium

Detail har jag ändrat till Medium (default är Low) för att få en lite mer detaljerad rapport som default.

Observera dock att du kan köra ytterligare en “override” när du startar skriptet, alltså med parametrar till logwatch programmet

Att kontrollera loggar på servern kanske inte hör till det roligaste, men det finns flera hjälpmedel.

Ett av dessa heter logwatch, vilket går igenom loggar och sammanställer det snyggt och prydligt i ett mail.
Installatras enkelt

$ sudo apt-get install logwatch

Read the rest of this entry »