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.
Még egy git-annex -szel lehetne színesíteni.