månadsarkiv: maj 2014

English

Running Samba in Linux in less than 5 minutes

So you want to share files over the network with perhaps windows machines or you want to be able to have networked file systems that are not requiring Kerberos to become secure but there are something fishy going on with your Samba installation?

Read on, here is the recipe to get it going. First of all make sure you have samba installed. An easy way to check this is to type the following two comnmands:

# service smbd status
 smbd start/running, process 27562
# service nmbd status
 nmbd start/running, process 27540

If either of those are not running, please install the samba package on your machine according to your OS recommendations, it may differ slightly depending on Linux distribution.

When you are done with this it’s time to modify the configuration file for Samba. Use your favorite editor (as root) and start by backing up your original configuration file.

# cp -a /etc/samba/smb.cfg /etc/samba/smb.bak

Then start your favorite editor and start off with this configuration:

[global]
 workgroup = WORKGROUP # change this to be unique on your network
 domain master = yes # there can only be one master
 local master = yes
 preferred master = yes
 os level = 65

 server string = %h server (Samba, Ubuntu)
 name resolve order = bcast host

 interfaces = 127.0.0.1 lo eth0
 bind interfaces only = yes

 log file = /var/log/samba/log.%m
 max log size = 10000
 syslog only = no
 syslog = 0

 map to guest = bad user

[guest]
 comment = networked file system
 path = /mnt/guest # set this to your preferred place
 read only = yes
 guest ok = yes

[anders]
 comment = private file system for anders
 path = /home/anders # be careful with your home folders
 read only = no
 guest ok = no
 valid users = anders

[google-drive]
 comment = private file system anders
 path = /mnt/raid/google-drive # another folder requiring password
 read only = no
 guest ok = no
 valid users = anders

[upload]
 comment = put your upload here
 path = /mnt/raid/upload # something where anyone can upload
 read only = no
 valid users = %S

Make sure the folders you have pointed out are actually valid folders. Then create the users needed to access the system:

# smbpasswd -a username

Type the password and create the users needed as per the shares that you have defined above. The valid users = %S means any user in the system can use that if they give the right password. To delete users from your samba system when no longer needed

# smbpasswd -x username

Next thing is to restard the name server for Samba and the actual server daemon:

# service nmbd restart
nmbd stop/waiting
nmbd start/running, process 28297
# service smbd restart
smbd stop/waiting
smbd start/running, process 28309

When this is done you should be able to connect giving the right username/password or as a guest if you have created the shares for the guest accounts.

Mounting the smb file system on a command line is done like this:

# mount -t cifs //server.name.or.ip/share /mnt/share -o username=yourname

If needed it will ask for your password also.

To list shares on an SMB server, use the following:

# smbclient -L //server.name.or.ip/ -U user%pass

You can skip -U user%pass if you prefer working as guest.

This should get you up and running easily. It’s not sophisticated and you have to manually work the passwords and they are not synced with with the rest of the users on the local machine, that is more complex to set up, this was meant to be a quick starter to get you going.

If you need to list the users in the database (to remove any you do not want any more) you can use the command:

# pdbedit -L

Read the man page for more information.

Swedish

TrueCrypt

Ingen vet riktigt vad som hände. Plöstligt försvann binärerna från deras site och i stället kom det upp en websida som sade att det ”kan finnas allvarliga säkerhetsproblem i TrueCrypt” och sedan hänvisar man till att använda BitLocker i stället.

Senaste versionen av TrueCrypt böts ut mot en version i vilken man bara kan dekryptera diskar och filer som tidigare krypterats med mjukvaran, men inte skapa nya volymer som är krypterade.

Det hela är bisarrt och det förekommer väl egentligen tre sorters teorier just nu:

  1. Truecryptsajten samt utvecklarnas datorer med deras nycklar som använts för att signera filerna med samt deras konto på sourceforge har alla blivit komprometterade i en hackerattack
  2. En riktigt riktigt allvarlig säkerhetslucka har upptäckts och för att få alla sluta använda mjukvaran tog man till drastiska metoder för att sätta projektet i brand och få alla sluta använda det
  3. Påtryckningar från någon regeringsmakt har fått utvecklarna bakom att i stället för att ge efter och t.ex. installera en bakdörr helt enkelt överge hela projektet.
  4. Utvecklarna bestod egentligen av en person som har fått nog och därmed överger projektet.

Men ingen av dessa teorier verkar vara särskilt vettiga. Fallet nummer 1 är relativt osannolikt och skulle tyda på att utvecklarna bakom ett säkerhetssystem haft rätt dålig säkerhet själva. Fallet nr 2 måste vara något helt spektakulärt och motsägs av att mjukvaran var under granskning och det första passet hade genomgåtts utan några större problem. Fall 3 verkar också märkligt, i detta fall borde vi aldrig märkt något alls men det kan ju vara så att någon i projektet verkligen vill blåsa i visselpipan. Nummer 4 är gissningsvis mer troligt men varför lämnar man inte programvaran vidare till andra att fortsätta den.

Som skäl till övergivandet uppges vara att Microsoft överger Windows XP och att det i senare versioner av operativsystemet finns andra lösningar som t.ex. BitLocker. Problemet är att den lösningen bara finns i vissa versioner av Windows 7 och 8, inte i exempelvis vista och det är heller inte på samma sätt som TrueCrypt en lösning som fungerar på flera plattformar där TrueCrypt fungerade utmärkt på flera versioner av Windows, MacOS och Linux.

Det fortfar alltså vara ett mysterium vad som hänt.

Swedish

Linux snapshots med rsync

En klurig sak man kan göra för att ordna med snapshots om filsystemet man använder inte stöder det är att göra ett lokalt backupskript som genererar sådana med jämna mellanrum. Men för att spara diskplats skulle man ju vilja ha möjligheten att bara spara förändringarna mellan varje snapshot samtidigt som det vore lätt att gå tillbaka t.ex. tre dagar i tiden utan problem.

Detta kan lösas med hårda länkar i Linux och det finns en hel del skrivet om det på nätet. Det intressanta med hårda länkar är att en fil som är länkad på det sättet fortsätter existera tills den sista länken är borttagen. Det är alltså ingen som helst skillnad mellan en hård länk och den egentliga filen.

Om du skapar fil A och sedan hårdlänkar den till fil B så är A och B på riktigt alltså samma fil. Om du ändrar A så ändras också B. Däremot om du raderar A så raderas inte B, länken är då bruten och man kan säga att B är lika mycket originalfilen som A en gång var. Nu kommer det riktigt intressanta: Om du skriver en ny fil A så existerar den separat från B. Länkningen mellan dem är bruten från när du raderade den.

En fil raderas egentligen aldrig men när den har 0 hårda länkar är den inte längre åtkomlig och platsen den tog upp på disken är nu fritt villebråd för andra filer att använda.

Ett intressant fenomen med rsync är att när den skriver filer gör den alltid delete på dem först! Eller egentligen gör den ”unlink”, det är ju ett bättre namn. Därför kan vi börja med att göra en rsync på filerna vi vill bevara. Exempelvis är det vanligt att man vill backa upp /etc /home /root i ett Linux-system.

Först skapar vi någonstans att hållas:

# mkdir /bup
# chown root:root /bup
# chmod 700 /bup

Därefter kan vi synka katalogerna till /bup/snapshot med kommandot:

# cd /bup
# rsync -a --delete /etc /home /root /bup/snapshot/

Om vi kör ovanstående (som root) kommer vi få en backup på de tre utpekade katalogerna i /bup/snapshot och de kommer vara kopior av de riktiga filerna. Nu kommer finessen. När vi vill spara vår snapshot kopierar vi dem men gör bara hårdlänknin från kopian. Genom att göra detta tar vi inte upp nämnvärt med displats och vi länkar till samma data på disken!

# cp -al snapshot snapshot.1

Du kan verifiera detta genom att slå

# du -sh *

Du kommer då se att det är betydligt mindre data i snapshot.1 än i snapshot och det beror på att det är bara länkarna i sig som vi har sparat på.

Nästa steg är att ta en ny snapshot med rsynk. När vi gör det kommer länkarna mallan snapshot och snapshot.1 att brytas i de filer som rsync uppdaterar eftersom den gör först unlink, sedan skriver en ny fil till den!

Om vi vill ha dagliga snapshots som roterar t.ex. tre dagar bakåt i tiden kan vi köra detta skript:

#!/bin/bash

cd /bup

if [ -x snapshot.2 ]; then
    mv snapshot.2 snapshot.3
fi

if [ -x snapshot.1 ]; then
    mv snapshot.1 snapshot.2
fi

if [ -x snapshot ]; then
    cp -al snapshot snapshot.1
fi

rsync -a --delete /etc /home /root /bup/snapshot/

Lägg sedan upp detta som ett cronjobb genom att redigera crontab (som root) med

# crontab -e

Lägg sedan till en rad exempelvis:

00 04 * * *     /root/backup-daily

Spar sedan skriptet ovan som /root/backup-daily så körs det kl 4 varje morgon så du alltid har en snapshot att gå tillbaka till om du gjort något klantigt i din hemkatalog…