Ubuntu Storage Instance

Hosszú történet előzi meg ezt a cikk írást. Nagyon régóta küzdök és próbálkozom különböző operációs rendszerekkel és azokon futó szolgáltatásokkal, hogy az ideális „Share” appliance-t kialakítsam. Egész eddig előnybe részesítettem a a szép felületet, és az átlátható management-et, ez pedig a szolgáltatások színvonalának romlásához vezetett.

Mit akarok?

Röviden és tömören:

– Pool alapú Logical Volume kezelés. Online bővítéssel.
– Actice Directory támogatás
– IPv6
– !SECURE!
– AFP (chroot)
– FTP (chroot)
– SMB (chroot)
– WebDAV (chroot)
– SFTP (chroot)
– SVN

Mi volt előtte?

A környezetemben ezt a szerepet nagyon régóta OSX Server látta el. Viszont időről időre annyira elkorcsosították a terméket, hogy teljesen alkalmatlanná vállt arra, amire használni akartam. Mivel több kiesést, és panaszt kellett megélnem, ezért váltani kellett. Be kell vallanom jogosan.

Storage Appliance specifikus termékek

Nagyon nagy elvárásokkal ugrottam bele az OpenFiler és FreeNAS rendszerekbe.

Magam is írtam róluk, de produktív tapasztalatom nem volt velük. Iszonyatosan pofára estem. Kínlódtam mindennel. Rugalmas és a sharing-re kihegyezett megoldást nem találtam. Ez van. Lehet én bénáztam, de egy hetes próbálgatás után csak felidegesítettem magam, és elhatároztam magam.

Építeni kell sajátot

Tudtam, hogy az igényeimhez már réges rég elérhetőek a toolok, és a beállításuk sem feltételeznek fejlesztői ismereteket. Így úgy voltam vele, mivel nem nagy számú „otthoni” felhasználó táborhoz kell a „megosztó szerver”, ezért egy Ubuntu Linuxból fogok készíteni elérhető programok segítségével Storage Appliancet.

Ubuntu 12.04 – Precise

Legtöbb eseten az Ubuntu Linux disztribúciót használom, viszont a továbbiakban, amennyiben valaki jobban kedvel más disztribúciót és a kívánt csomagok ott is elérhetőek, akkor használjon azt.

Magam a legfrisebb LTS kiadást raktam fel.

Az alap rendszer telepítését nem kívánom bemutatni, illetve az alapértelmezett LVM-et sem. Az LVM képességeiről már írtam Linuxon.

IPv6 is alapból támogatott ebben az Ubuntu verzióban, és hála a v6 tunnelemnek és az Airport Extreme routernek automatikusan jár a IPv6 cím. Lásd a leírást itt.

Tehát a listáról két pont is kipiálva.

– Pool alapu Logical Volume kezelés. Online bővítéssel.
– IPv6

Active Directory integráció

Régebben hihetetlen erőfeszítésbe telt, hogy a LINUX rendszer tudja használni az AD-ben elérhető információkat.

Jó magam régóta a Likewise-Open alkalmazást használom ennek a megoldására. A tool minden olyan komponenst tartalmaz, amivel az active directory integráció megvalósítható. Sőt! A fizetős verzióban igazán varázslatos módon lehet Windows környezetbe varázsolni a Linux-unkat. Group Policy és egyéb nyalánkságok.

Jelenleg számomra elégségesnek bizonyult, hogy a Linux szintű felhasználó kezelésbe integráljam az AD usereket.

Ehhez először is telepíteni kellett a csomagot, ami alapból elérhető volt a repository-ban:

# apt-get install likewise-open

Ezek után nincs más dolgunk, mint ahogy Windows esetében is beléptetni a Domain-be.

# domainjoin-cli join sajt.hu Administrator

A fenti parancs esetében a sajt.hu a Domain, illetve az Adminisztrator felhasználóval azonosítom magam. A jelszó megadása után kész is. Egy újraindítást ajánlatos, de már a parancs sikeres lefutása után elérhetőnek kell lenni a Active Directory-s felhasználók illetve csoportok.

# id SAJT\\miszterx
uid=1450143202(SAJT\miszterx) gid=1450142593(SAJT\domain^users) groups=1450142593(SAJT\domain^users)

Ahogy látszik az AD-s felhasználók nevében szerepelni fog a DOMAIN neve. Tehát hivatkozni rájuk, illetve belépni is úgy lehet, hogy DOMAIN\username.

Sajnos Linux alatt a „\” karakter speciális vezérlő karakter, így ahhoz, hogy értelmezze a Linux még egy \ jelet kell tenni. Tehát Linux/Unix rendszerekről sshzva:

# ssh SAJT\\miszterx@stoarage

Tehát egy paranccsal és egy csomaggal megoldva az AD integráció. Személyes tapasztalat köze 50 ilyen rendszer után, hogy megy, nincs vele gond és egyszerű.

(Akit zavarja a DOMAIN kezelése az a következő parancs segítségével kikapcsolhatja:

# lwconfig AssumeDefaultDomain true
)

Ezzel az Active Directory pont is kipipálva.

– Actice Directory támogatás

Biztonság

Először is szeretném definiálni nálam ez a !Secure! dolog mit jelent. Alapvetően minden kommunikáció támogassa a titkosított TLS/SSL lehetőséget, illetve ezen túl teljes mértékben korlátozni a szolgáltatások ki számára érhetőek el.

Ezekre a dolgokra egyesével minden megosztás esetében ki akarok térni, de először vizsgáljuk meg magát az SSH-t. Ugye az Active Directory kapcsolattal a Linux-unk sajátjaként kezeli az összes AD user-t is. Ami nem feltétlenül szerencsés, ha mindenki mindenhova be tud lépni.

Hozzunk létre az Active Directory-ban egy csoportot, akár globálisan, akár gépenként, amihez AD-ben tudunk hozzárendelni embereket.

Ezek után szerkesszük meg a következő file-t:

# vi /etc/ssh/sshd_config

Illeszük be a végére a következő sort:

AllowGroups SAJT\ssh^users

Ebben az esetben az „ssh users” Active Directory csoport tagjai léphetnek be.

Indítsuk újra az ssh-t.

# /etc/init.d/ssh restart

Amennyiben engedélyezett felhasználó akar belépni a logokban a következőt fogjuk látni:

Aug 15 16:01:02 sajt-storage sshd[18970]: Accepted keyboard-interactive/pam for SAJT\\miszterx from 10.0.0.200 port 62422 ssh2
Aug 15 16:01:02 sajt-storage sshd[18970]: pam_unix(sshd:session): session opened for user SAJT\miszterx by (uid=0)

Amennyiben valaki nincs a listán:

Aug 15 16:06:24 sajt-storage sshd[19755]: User localadmin from 10.0.0.200 not allowed because none of user’s groups are listed in AllowGroups
Aug 15 16:06:24 sajt-storage sshd[19755]: input_userauth_request: invalid user localadmin [preauth]
Aug 15 16:06:24 sajt-storage sshd[19755]: Postponed keyboard-interactive for invalid user localadmin from 10.0.0.200 port 62535 ssh2 [preauth]
Aug 15 16:06:26 sajt-storage sshd[19757]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.200 user=localadmin

FTP

Kezdjünk is bele a megosztásokba. Az első nálam az FTP lett. Varga Tamás kollégám javaslatára a vsftpd-t választottam.

Telepítés egyszerű, mert repository-ban megtalálható:

# apt-get install vsftpd

Ezek után testre kell szabnunk a konfigurációs állományát.

# cat /etc/vsftpd.conf
# Ne csak IPv4-en figyeljen.
listen=NO
# Furcsam, de ezt kell CSAK yes-re állítanunk, ha azt akarjuk, hogy v4 és v6-on is figyeljen.
listen_ipv6=YES
# Nekem nincs szükségem Anonymous opcióra.
anonymous_enable=NO
# local felhasználókat akarunk, ha mar az AD-t bekötöttük oda
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
idle_session_timeout=600
data_connection_timeout=120
# Chroot bekapcsolása
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
# SSL támogatása
ssl_enable=YES
allow_anon_ssl=NO
# Titkosítatlan csatornákat IS elfogadjon
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
# A következő három sorral, sajnos csak egy külön file-ban adhatjuk meg az FTP képes felhasználók sorát.
userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd.allowed_users
# Maximum mennyi kapcsolatot engedélyezünk egy IP-ről.
max_per_ip=2
# Összesen mennyi felhasználó.
max_clients=10

Tehát van IPv6, SSL, Chroot, illetve sajnos csak egy külön file alapján de tudjuk limitálni, milyen felhasználóknak adunk FTP szolgáltatást.

A vsftpd-nek van egy furcsasága, ami viszont máshol is megjelenik chroot környezeteknél. Mégpedig az, hogy a CHROOT könyvtárat nem lehet írni, csak az az alatt lévőket. Amennyiben a következő hibaüzenettel találkozunk, ez lesz a gond:

500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

Én ezt elfogadtam, és a következő cron scriptet állítottam be, hogy ezt biztosítsam:

# crontab -e
1,11,21,31,41,51 * * * * getent passwd | awk -F: ‘$(NF-1)~/home/ {print „chmod a-w „$(NF-1)}’|sh 2> /dev/null

Tehát még egyszer! A felhasználóink, nem fogják tudni írni közvetlenül a HOME könyvtárukat, csak és kizárólag a benne lévő könyvtárakat. Ezért is alakítottam ki már Windows, OSX, Linux-ból ismert struktúrát:

SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:39 .
root root 4.0K Aug 14 11:47 ..
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:52 Application
SAJT\miszterx SAJT\domain^users 2.1K Aug 15 15:48 .bash_history
SAJT\miszterx SAJT\domain^users 220 Aug 14 11:47 .bash_logout
SAJT\miszterx SAJT\domain^users 3.5K Aug 14 11:47 .bashrc
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:39 Documents
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:39 Download
SAJT\miszterx SAJT\domain^users 17 Aug 14 11:47 .k5login
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:39 Pictures
SAJT\miszterx SAJT\domain^users 675 Aug 14 11:47 .profile
SAJT\miszterx SAJT\domain^users 0 Aug 14 17:22 sajt
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 19:39 Sites
SAJT\miszterx SAJT\domain^users 4.0K Aug 14 17:23 .ssh

Akkor ez letudva!

– FTP (chroot)

SFTP

Az SFTP az SSH-n belüli alrendszer, ami a fájlműveletekért felel. Ezt kell chroot környezetbe illesztenünk, és megint csak definiálni kinek jár ilyen.

Mivel SSH hozzáférésre már létrehoztunk egy csoporot, ezért az SFTP csoportot rajuk bele ebbe az „ssh users” csoportunkba. Ellenkező esetben előfordulhatna, hogy valakinek adtunk SFTP chroot szolgáltatást, de SSH tiltva van.

Amennyiben ez megvan, a következő kódrészletet kell beillesztenünk a konfigurációs file végére.

# vi /etc/ssh/sshd_config

Subsystem sftp internal-sftp
Match Group sftp
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Majd indítsuk újra az SSH-t.

# /etc/init.d/ssh restart

Próbáljunk most valahonnan SSH-zni egy olyan felhasználóval, akit SFTP chrootra korlátoztunk:

$ ssh localadmin@10.0.0.88
Password:
This service allows sftp connections only.
Connection to 10.0.0.88 closed.

Láthatóan errort kapunk. Plusz meg is kapjuk, hogy ez csak SFTP-re lett beállítva.

$ sftp localadmin@10.0.0.88
Connecting to 10.0.0.88…
Password:
sftp> ls
sftp>

SFTP-vel próbálkozva viszont tökéletes. Nézzük ezt most szerver logok felől:

A hibás próbálkozásból semmi se látszik:

Aug 15 17:00:18 sajt-storage sshd[20811]: Accepted keyboard-interactive/pam for localadmin from 10.0.0.200 port 63638 ssh2
Aug 15 17:00:18 sajt-storage sshd[20811]: pam_unix(sshd:session): session opened for user localadmin by (uid=0)
Aug 15 17:00:19 sajt-storage sshd[20811]: pam_unix(sshd:session): session closed for user localadmin

Az SFTP kapcsolat esetén viszont látszik, hogy az SFTP subsystemet megkapta a felhasználó:

Aug 15 17:00:27 sajt-storage sshd[20959]: Accepted keyboard-interactive/pam for localadmin from 10.0.0.200 port 63680 ssh2
Aug 15 17:00:27 sajt-storage sshd[20959]: pam_unix(sshd:session): session opened for user localadmin by (uid=0)
Aug 15 17:00:28 sajt-storage sshd[21105]: subsystem request for sftp by user localadmin

Így az SFTP is kihúzva.

– SFTP (chroot)

WebDAV

A WebDAV egy HTTP és HTTPS protokollokon alapuló, file műveleteket elősegítő megosztási forma. Én az OSX és főleg az iOS esetében ismertem meg ezt a sharinget. Nagy előnyként kell megemlítenem, hogy alap esetben egy mountolható / csatolható tárterületként jelenik meg, ahol file műveleteket végezhetünk, akár csak a lokális állományainkkal. További nagyon fontos, hogy amennyiben a WebDAV megosztáson belül mozgatunk, akkor az megoldódik a távoli helyen, nem kell lemásolnunk magunkhoz, hogy utána az új helyre töltsük fel.

Annak ellenére, hogy ez tűnik az új generációs megoldásnak, számtalan sebből vérzik.

– Windows elég macerásan hajlandó kezelni
– Nincs saját WebDAV share alkalmazás, az Apache-t kell megerőszakolni.
– Webszerver miatt speciális jogosultságok szükségesek a könyvtárunkra.
– Symlinkeket nem kezel a WebDAV.
– !! Windows alatt csak és kizárólag Hivatalosan aláírt Certificatedek elfogadottak !!

Így aki ilyet akar, az rengeteg megkötéssel kell, hogy szembe nézzen.

Először is kell egy Apache instance PAM Auth modullal.

# apt-get install libapache2-mod-auth-pam apache2-mpm-worker

Az első maga a szükséges apache csomag, a másik pedig az a PAM modulja, amivel elérhetővé válik a felhasználó azonosítás a web szerveren belül.

A telepítést követően el kell kezdeni konfigurálgatni.

Először is ellenőrizzük, hogy a DAV és PAM modulok engedélyezve vannak-e:

# ls -lah /etc/apache2/mods-enabled/auth_pam.load
/etc/apache2/mods-enabled/auth_pam.load -> ../mods-available/auth_pam.load

# ls -lah /etc/apache2/mods-enabled/dav*
/etc/apache2/mods-enabled/dav_fs.load -> /etc/apache2/mods-available/dav_fs.load
/etc/apache2/mods-enabled/dav.load -> /etc/apache2/mods-available/dav.load
/etc/apache2/mods-enabled/dav_lock.load -> /etc/apache2/mods-available/dav_lock.load

Amennyiben nem létezne itt a symlink, akkor kézzel tegyük meg. A továbbiakban én feltételezek APACHE konfigurációs tudást, és nem veszem sorról sorra, mit mért és hogyan kell beállítani egy működőképes apache web szerverhez. Csupán a WebDAV specifikus konfigurációt mutatom be.

Egyetlen engedélyezett site konfigurációs állományom van.

# ls -lah /etc/apache2/sites-enabled/
01-webdav -> /etc/apache2/sites-available/miszterx

A konfigurációs állomány tartalma pedig így néz ki:

<VirtualHost *:443>
  ServerName file.sajt.hu
  ServerAdmin webmaster@sajt.hu
  DocumentRoot /var/www/empty
  DirectoryIndex index.html
  CustomLog /var/log/apache2/webdav-access.log combined
  ErrorLog /var/log/apache2/webdav-error.log

# SSL engine start and harden it
  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

  SSLCertificateFile /etc/apache2/ssl/sajt-storage.sajt.hu.crt
  SSLCertificateKeyFile /etc/apache2/ssl/sajt-storage.sajt.hu.key
  SSLCertificateChainFile /etc/apache2/ssl/startssl.chain.cl1.crt
  SSLCACertificateFile /etc/apache2/ssl/startssl.ca.crt
  SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

# User WebDAV share definition
  Alias /webdav/miszterx   /home/likewise-open/SAJT/miszterx
  <Location /webdav/miszterx>
    DAV on
    AuthName "MiszterX WebDAV Home"
    AuthType Basic
    AuthPAM_Enabled on
    AuthBasicAuthoritative off
    AuthUserFile /dev/null
    require user SAJT\miszterx
   </Location>
</VirtualHost>

Akkor kicsit vesézzük ki, mit is láthatunk fent. Definiáltunk egy új VHOST-ot. Megadtuk a kötelező értékeket. Lentebb beállítottuk az SSL kapcsolathoz szükséges paramétereket és kulcsokat, certeket.

Ezek után jön egy User Share definíció. Amennyiben több felhasználónk is van ebből a részből kell többet is létrehoznunk. Documentum root-nak én egy üres könyvtárat adtam meg, és ALIAS-al hivatkoztam arra a HOME könyvtárra, amit meg akarok osztani.

Majd bekapcsoltam egy LOCATION tag-be kezdtem el definiálni a DAV megosztás paramétereit. Fontos, hogy Basic, tehát titkosítatlan autentikációt tudunk csak használni, ezért is fontos az SSL kapcsolat. Amennyiben az AuthPAM_Enable be van kapcsolva, lokális felhasználóinkat is meghivatkozhatjuk. Ennyi is.

Windows 7 HTTPS kálvária

Hihetetlen sok fejtörést okozott, hogy a fenti konfiguráció, miért CSAK Windows-on nem akart működni. OSX, LINUX csodálatosan felcsatolta. A Windows viszont nem. Én a továbbiakban csak Windows 7-el fogok foglalkozni.

Különböző error-okat kaptam, de ami a célra vezetett végül az ez volt:

C:\Users\User>net use * „https://sajt-storage/webdav/miszterx”
System error 59 has occurred.
An unexpected network error occurred.

Nagy nehezen százával olvasva a fórumokat kellett rájönnöm, hogy HTTPS WebDAV megosztást a Windows 7 csak és kizárólag akkor támogatja, amennyiben a Web Szerver titkosítási kulcsa Microsoft által elismert szervezet alapján van hitelesítve. Tehát nem fog menni a WebDAV ha self-signed certificate-t használsz! Jó mi? Persze erre egy normális error se hívja fel a figyelmet.

Szerencsére napjainkban van mód ingyenes otthoni használatú aláírást szerezni a WebDAV szerverünkhöz.

A következőekben a https://www.startssl.com oldal megoldását fogom bemutatni, ezzel nekem tökéletesen működött a WebDAV Windows 7-el.

Ingyenesen lehet regisztrálni, majd a megfelelő authentication kulcs segítségével be is jutunk a profilunkba. Menünk a Valiadation Wizard-ba, ahol be kell bizonyítanunk, hogy a domain, amihez hitelesítést kívánunk igényelni a sajátunk.

Majd adjuk meg az ellenőrizni kívánt domain-t.

Válasszuk ki, hogy a domain-hez kötött emailcímek közül melyikre szeretnénk ellenörző levelet kapni.

Amint megérkezett az email másoljuk be a mezőbe kódot. Majd lépjünk tovább.

Ezek után menjünk át a Certificated Wizard menüre és válasszuk a WebServer TLS/SSL Certificate menüpontot.

Most kell készítenünk a gépünkön egy kulcsot, és hozzá egy aláírást kérvényező file-t. Adjuk ki a következő parancsot.

# openssl req -new -newkey rsa:4096 -days 365 -nodes -keyout sajt-storage.key -out sajt-storage.csr

A parancs be fog kérni több adatot is, ezekre válaszoljunk, majd a végén létrejön egy sajt-storage.key és egy sajt-storage.csr állomány.

A webes felületen kattintsunk a SKIP gombra. Majd a megjelenő ablakba másoljuk be a sajt-storage.csr file TELJES tartalmát.

Adjuk meg a domain-hez tartozó hostnevet.

Egy megerősítést fogunk kapni, milyen hostokat fog támogatni a cert.

Ezek után fogjuk megkapni a Cert-et, amit teljes egészében mentsünk le sajt-storage.crt néven.

Jelenleg tehát három file-unk van. Én ezeket a /etc/apache2/ssl könyvtárban tároltam.

# ls -lah /etc/apache2/ssl
sajt-storage.key <- generáltuk
sajt-storage.csr <- generáltuk (továbbiakban törölhető)
sajt-storage.crt <- letöltöttük, a CSR kérésünkből

A továbbiakban két file-t kell még letöltenünk a StartSSL.com-ról. Menjünk a ToolBox tab-ra, majd ott a StartCom CA Certificates menüre kattintva egy hosszú lista jelenik meg. Töltsük le a StartCom Root CA (PEM encoded) és a Class 1 Intermediate Server CA certeket.

A StartCom Root CA (PEM encoded) certificate ca.pem néven a Class 1 Intermediate Server CA sub.class1.server.ca.pem néven fog mentődni.

Ezek et is másoljuk a /etc/apache2/ssl alá.

# ls -lah /etc/apache2/ssl
sajt-storage.key <- generáltuk
sajt-storage.csr <- generáltuk (továbbiakban törölhető)
sajt-storage.crt <- letöltöttük, a CSR kérésünkből
sub.class1.server.ca.pem <- letöltöttük
ca.pem <- letöltöttük

Ezek után a következő parancsokat adjuk ki.

# cd /etc/apache2/ssl
# mv ca.pem startssl.ca.crt
# mv sub.class1.server.ca.pem startssl.sub.class1.server.ca.crt
# cat startssl.sub.class1.server.ca.crt startssl.ca.crt > startssl.chain.cl1.crt
# cat sajt-storage.{key,crt} startssl.chain.cl1.crt > sajt-storage.pem
# ln -sf sajt-storage.pem apache.pem
# chown www-data *.crt *.key *.pem
# chmod 640 *.key *.pem

Ezek után indítsuk újra az apache-t és már is működnie kell hitelesített webdav tárhelyünknek, ami immár Windows 7-el is működik.

Így a WebDAV is kipipálva.

– WebDAV (chroot)

AFP

Az AFP nem más mint az Apple saját file megosztási protokollja. Apple File Protocol. Egyrészről áll egy Netatalk szolgáltatásból, másrészről egy Bonjure szolgáltatásból, ami hirdeti magát a hálózatban.

Telepítsük a komponenseket a repositoryból.

# apt-get install netatalk avahi-daemon

Az Avahi-Deamon fogja biztosítani Linux esetében a Bonjure service-t.

Nézzük először az AFP konfigurációs állományait. Több config file is van, de a legtöbb opció ki lesz kommentezve, ezekre nekünk nem is lesz szükségünk az alap működéshez.

/etc/netatalk/afpd.conf:
-tcp -noddp -ipaddr :: -setuplog „default log_debug /var/log/afp.log” -uamlist uams_dhx.so,uams_dhx2.so -nosavepassword

/etc/netatalk/afp_signature.conf:
„sajt-storage” EF954EAA56846FC67FD750804F3679E1

/etc/netatalk/AppleVolumes.default:
:DEFAULT: options:upriv,usedots

/etc/netatalk/AppleVolumes.default:
/home/likewise-open/SAJT/miszterx/ „MiszterX Home AFP Share” allow:SAJT\miszterx

Az első bejegyzés szükséges az IPv6 és IPv4 hálózatok támogatására, továbbá, hogy a jelszavunkat megfelelő titkosítással kezelje az AFP daemon.

A signature file-ban a bejegyzés automatikusan jön létre. Ez lesz az AFP server egyedi azonosítója.

Az AppleVolumes.default file-ban kell definiálnunk a share-ket. Alapból a upriv és usedots opciók lesznek bekapcsolva, ami az én esetemben elegendőnek is bizonyult. A hivatalos man-jában elérhető az összes opció. Az allow: után sorolhatjuk fel a felhasználóinkat, vagy csoportokat. Csoportok esetén @-al kell kezdenünk, és több esetén „,” vesszővel kell elválasztanunk őket.

Amint definiáltuk a megfelelő megosztásokat, csak indítsuk újra a service-t.

# /etc/init.d/netatalk restart

Ahogy említettem a Bonjure szolgáltatásról is gondoskodnunk kell. Ehhez először is ellenőrizzük a avahi-deamon.conf file-t.

#|^$” /etc/avahi/avahi-daemon.conf
[server]
use-ipv4=yes
use-ipv6=yes
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
[reflector]
[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3

Ez az alap konfiguráció. IPv4 és IPv6 támogatással együtt.

Nincs más dolgunk mint az AFP service-re létrehozni egy új elemet. Ehhez hozzuk létre a következő file-t és emeljük bele a következő t

# vi /etc/avahi/services/afpd.service

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
    <name replace-wildcards="yes">%h</name>
    <service>
        <type>_afpovertcp._tcp</type>
        <port>548</port>
    </service>
    <service>
        <type>_device-info._tcp</type>
        <port>0</port>
        <txt-record>model=Xserve</txt-record>
    </service>
</service-group>

Ez fogja az AFP szolgáltatást hirdetni, és a gépünket a 548-as porton (az AFP megosztás) hirdetni az OSX gépek számára. A Model résznél tetszőlegesen megadhatunk egy gépet. Ennek a gépnek az ikonja fog megjelenni az OSX-eken. A következő típusok értelmezhetőek: Macmini, iMac, MacPro, Xserve, MacBook, MacBookPro vagy MacBookAir.

A módosítások után indítsuk újra a service-t:

# /etc/init.d/avahi-daemon restart

Tehát az AFP is megy IPv6 is, secure is, alapból chroot-olt.

– AFP (chroot)

Samba

A samba jól ismert olyan helyeken, ahol valamilyen Linux/Unix rendszert kell Windows környezetben hasznosítani. Én a megannyi tudása mellette, csak és kizárólag a Windows Share vagy Samba Share funkcióját kívánom kihasználni.

Először is telepítsük a repository csomagot:

# apt-get install samba

Ezek után viszont szükségünk lesz a LikeWise legújabb 7.0-s verziójára, mert csak az fogja támogatni, a SAMBA 3.6.3 integrációját!

Töltsük le innen.

( A felhasználó névben a DOMAIN használatának kikapcsolása: /opt/pbis/bin/config AssumeDefaultDomain true
A felhasználók shelljének BASH-re állítása: /opt/pbis/bin/config LoginShellTemplate /bin/bash
A motd mutásának bekapcsolása: /opt/pbis/bin/config DisplayMotd true
)

Újra léptessük be a domain-be a gépünket, amennyiben szükséges:

# domainjoin-cli join sajt.hu Administrator

Ezek után ellenőrizzük, hogy a LikeWise és a Samba verziónk támogatják-e egymást.

# samba-interop-install –check-version
Found smbd version 3.6.3
Samba version supported

Amennyiben igen, csupán egyetlen parancsot kell kiadnunk.

# samba-interop-install –install
Found smbd version 3.6.3
Install successful

Ennek hatására, máris létrejött a LikeWise Active Directory képességének Samba irányában való kiterjesztése.

Én a következő konfigurációval indítottam el a samba-t:

# grep -v „#” /etc/samba/smb.conf |grep -v „;”|grep -v ^$

[global]
   workgroup = SAJT
   realm = SAJT.HU
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   log level = 1
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = ADS
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = no
   unix password sync = no
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:*
 %n\n  *Retype\snew\s*\spassword:*
 %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
# Printer errorok kiiktatása
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes
   idmap uid = 10000-33554431
   idmap gid = 10000-33554431
# Share definíció
[MiszterX]
	comment = MiszterX Samba Share
	path = /home/likewise-open/SAJT/miszterx/
	browseable = yes
	guest ok = yes
	read only = no
	valid users = @"SAJT\Domain Admins"

Indítsuk újra az új konfigurációval:

# /etc/init.d/smbd restart

Ahogy látszik, a valid users-nél csoportot definiáltam, természetesen egyetlen felhasználót is lehet. Nagyon fontos, hogy a Likewise integráció miatt, elérhető lesz a Kerberose Single-Sing-On, tehát, amennyiben egy DOMAIN-ben van a kliens, és a szerver, abban az esetben külön authentikációra sem lesz szükség.

IPv6, Single sing on, Samba share, chrootolt, tehát ez is megvan!

– SMB (chroot)

SVN

Az SVN egy verziókövető rendszer, mely leginkább fejlesztők munkájában elterjedt. Az SVN segítségével, nyomon lehet követni a dokumentumok változását, főleg a szöveges dokumentumokét. Mikor, ki milyen sorokat változtatott meg, és miért. Természetesen, akár mikor visszanyúlhatunk, akár melyik verzióhoz.

Az SVN nem csak a fejlesztőknek lehet érdekes, akárkinek aki felismeri a verziókövetés fontosságát. Az SVN-nek hála akármilyen dokumentumot tárolhatunk a repository-kban. Én egy olyan módszert fogok bemutatni, ahol a már meglévő Apache webszervert felruházom SVN tudással is.

Először is telepítsük a szükséges csomagokat.

# apt-get install libapache2-svn

Ellenőrizzük, hogy az SVN modulok be vannak-e töltve. Ha nem kézzel hozzuk létre a symlinkeket.

root@xorp-storage:~# ls -lah /etc/apache2/mods-enabled/*svn*
lrwxrwxrwx 1 root root 30 Aug 14 16:28 /etc/apache2/mods-enabled/dav_svn.conf -> ../mods-available/dav_svn.load

A WebDAV-nál már megismert szerkeszetet fogom használni, egy új virtualhost beállításánál.

<Virtualhost *:443>
 ServerName trac.sajt.hu:443
 ServerAdmin webmaster@xorp.hu
 DocumentRoot /var/www/empty
 DirectoryIndex index.php
 LogLevel warn
 CustomLog /var/log/apache2/trac-access.log combined
 ErrorLog /var/log/apache2/trac-error.log

 SSLEngine on
 SSLProtocol all -SSLv2
 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM	
	
 SSLCertificateFile /etc/apache2/ssl/sajt-storage.sajt.hu.crt
 SSLCertificateKeyFile /etc/apache2/ssl/sajt-storage.sajt.hu.key
 SSLCertificateChainFile /etc/apache2/ssl/startssl.chain.cl1.crt 
 SSLCACertificateFile /etc/apache2/ssl/startssl.ca.crt
 SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

 <Location "/">
     AuthName "trac"
     AuthType Basic
     AuthPAM_Enabled on
     AuthBasicAuthoritative off
     AuthUserFile /dev/null
     require user XORP\miszterx
 </Location>
 <Location "/doc">
     DAV svn
     SVNPath /var/svn/doc
     SVNListParentPath on
     AuthType Basic
     AuthPAM_Enabled on
     AuthBasicAuthoritative off
     AuthUserFile /dev/null
     require user SAJT\miszterx
 </Location>
 <Location "/development">
      DAV svn
      AuthName "Development"
      SVNPath /var/svn/development
      SVNListParentPath on
      AuthType Basic
      AuthPAM_Enabled on
      AuthBasicAuthoritative off
      AuthUserFile /dev/null
      require user SAJT\miszterx
 </location>
</virtualhost>

Location tag-ekben definiáltam a meglévő SVN repository-kat. Fontos, hogy ezek a repositoryk, ne a WWW struktúránk alatt legyenek. SVNPath változó után kell a repository PATH-át megadni a gépünkön. Illetve opcionálisan bekapcsolható a SVNListParentPath, mely indexeket fog nekünk mutatni. Ahhoz, hogy ez a megosztás ne sima WebDAV megosztás legyen, figyelnünk kell, hogy a DAV után ne ON hanem SVN szerepeljen.

Ezzel kész is vagyunk.

– SVN

Transmission – Torrent

A Transmission közvedvelt torrent kliens. Nagyon sok embedded / beágyazott storage rendszert készítő cég használja ezt a programot. Kevesen vannak viszont, akik a transmission-t hagyják, hogy távolról vezérelhessük. Sokszor kényelmetlen belépteni egy webes felületre, és feltölteni egy file-t. Mennyivel egyszerűbb lenne, ha a lokális kliensünk egy távoli géphez kapcsolódna.

Ezt egyszerűen megoldhatjuk a Transmission-nal.

Ehhez először is adjunk egy új repository-t a gépünkhöz.

# add-apt-repository ppa:transmissionbt/ppa
# apt-get update

Telepítsük a következő csomagot:

# apt-get install transmission-daemon

Ezek után szerkesztenünk kell az egyetlen konfigurációs állományát:

# vi /etc/transmission-daemon/settings.json

  "bind-address-ipv4": "0.0.0.0", 
  "bind-address-ipv6": "::", 
  "blocklist-enabled": true, 
  "blocklist-url": "http://www.bluetack.co.uk/config/level1.gz", 
  "download-dir": "/home/likewise-open/SAJT/miszterx/Downloads", 
  "rpc-authentication-required": true, 
  "rpc-bind-address": "0.0.0.0", 
  "rpc-enabled": true, 
  "rpc-password": "{d964d00e43gfd42fsd34fsd23af5oSN.UEm.", 
  "rpc-port": 9091, 
  "rpc-url": "/transmission/", 
  "rpc-username": "miszterx", 
  "rpc-whitelist": "192.168.0.*", 
  "rpc-whitelist-enabled": true, 

Rengeteg paraméter állítható a torrentezéssel kapcsolatban. Én viszont kiemeltem néhány sort, amit érdemes megemlíteni. A bind address-nél tudjuk megadni, hogy IPv4 és IPv6-on is elérhető legyen a szolgáltatás. Blocklistet én szeretem használni, sok kellemetlen helyzettől óvhatjuk meg magunkat, bár nem mindentől. A Download dir-ben definiálhatjuk előre, hogy hol legyen az alapértelemzett letöltési helyünk. Ezeket eddig mind-mind felülbírálhajtjuk majd a kliensben.

Ami ennél is fontosabb, maga az RPC service beállítása. Itt kell megadjunk, milyen IP-n, milyen porton legyen elérhető az remote elérés. Milyen felhasználói névvel, és milyen jelszóval. Természetesen ezt a kapcsolatot akár hálózati címre, vagy címekre is korlátozhatjuk. A legfontosabb pedig a jelszó. Ne ijesszen meg senki, hogy ott egy hash-t lát. Írjuk be nyugodtan plain text-el a jelszavunkat, majd a service újratöltődésénél automatikusan hash generálódik belőle.

Fontos, hogy ahhoz, hogy az új konfigurációnk betöltődjön először újra kell olvastatni a kofigurációs állományt.

# /etc/init.d/transmission-daemon reload
Majd újraindítani, ezzel pedig érvényesülnek a definíciók.
# /etc/init.d/transmission-daemon restart

Amennyiben egyből restartolunk, az előző betöltött konfiguráció fog felülíródni.

Összegzés

Remélem sikerült átfogóan bemutatni, hogy mennyire egyszerű egy Ubuntu rendszerrel, és a rá elérhető csomagok segítségével, mindenre kiterjedő, biztonságos, IPv6-ot is támogató Storage Instance-t létrehozni.

Nagyszerűen működik, a lehető legkevesebb erőforrást igényli. Az egyetlen negatívuma a share és hozzáférés adminisztráció.

Legtöbb esetben konfiguráció kézi szerkesztése módja, minden konfiguráció pedig különböző.

Így akinek rendszeresen kell megosztásokat managelni, illetve felhasználók jogkörét változtatni, annak nem egy ideális megoldás. Én most úgy érzem, egy hosszabb távon karban tartott és működő rendszert építettem. Az én esetemben kevés számú felhasználónak kell, egyszer definiálni a jogkörét, így a viszontagságai számomra elfogadhatóak, cserébe, hogy minden működik, ahogy kell.

Szívesen várom a visszajelzéseket, illetve más leírásokat, amik az említett szolgáltatásokkal foglalkoznak.

Ubuntu Storage Instance” bejegyzéshez egy hozzászólás

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük