A műsor természetesen ivással és a kártyák megkezdésével kezdődött. A kártyák speciálisan az eseményre készített lapok voltak, melyekre Lili és Attila képei voltak rámontírozva. Ezen kártyák tartalmaztak minden féle utasítást az ünnepelt számára. Természetesen több utasítás már már a törvényesség és a jóindulat határát súrolta, viszont valahogy meg kellett mérettetni a szerelmes férfit a nagy nap előtt.

Millió apró kérdésre kellett válaszolni a múltból, amire ha helytelen választ adott, innia kellett. Viszont voltak nagyobb események is. Az első mindjárt egy gokartozás volt, a második pedig strandfoci. Az elszántságunkat és a megfelelő ittas állapotot jellemzi, hogy a hideg és az eső ellenére is mindkettőt megvalósítottuk.

Az estét végül is egy vacsorával és egy lány táncolásával fejeztük be a helyen, és a csapat elindult a városba mulatni. A hangulat jó volt, személyi sérülés nem történt, és az anyagi kár sem jelentős.

Az eseményen készült minden kép megtekinthető itt.

Mi az a profile?

Ugye emlékszünk legutoljára milyen paranccsal tudtunk egy kliens már inicializálni?

#ldapclient manual -v
-a credentialLevel=proxy
-a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=oss
-a proxyPassword=ossproxy
-a defaultSearchBase=dc=test,dc=oss
-a defaultSearchScope=sub
-a domainName=test.oss
-a serviceSearchDescriptor=passwd:dc=test,dc=oss?sub
-a serviceSearchDescriptor=shadow:dc=test,dc=oss?sub
-a serviceSearchDescriptor=group:dc=test,dc=oss?sub
-a serviceAuthenticationMethod=pam_ldap:simple
-a authenticationMethod=simple
-a attributeMap=automount:automountKey=cn
-a attributeMap=automount:automountInformation=nisMapEntry
-a attributeMap=automount:automountMapName=nisMapName
-a serviceSearchDescriptor=auto_master:automountMapName= auto_master,dc=test,dc=oss?sub
-a serviceSearchDescriptor=auto_home:automountMapName= auto_home,dc=test,dc=oss?sub
192.168.132.1

Ez elég undorító. Mielőtt rátérnék arra, hogy miben segít nekünk a profile, nézzük meg az inicializálás után, ezen információkat, hol tárolja el az LDAP client.

# cd /var/ldap/
# ls -lah

Ebből is a ldap_client_file file lesz számunkra érdekes:

# cat ldap_client_file

Ebben a file-ban, minden szépen össze van szedve. Mihez csatlakozunk, hogy, milyen DN alatt mit találunk meg. Csak úgy, ahogy az "ldapclient manual" parancsban összefoglaltunk. Na de, ha ez ilyen szépen strukturáltan dolgozódik fel a kliensekben, akkor miért ne tárolhatnánk eleve így, központosítva az LDAP-ban.

Profile struktúra az LDAP-ban

Szerencsére ahhoz, hogy profil objektumokat tudjunk létrehozni, nem kell új sémákról gondoskodnunk, az eddigiekkel is menni fog.

A következő LDIF file-t használtam én.

# cat /tmp/openldap_install/ldifs/automount_profile.ldif
dn: cn=automount_profile,ou=profile,dc=test,dc=oss
ObjectClass: top
ObjectClass: DUAConfigProfile
defaultServerList: 192.168.132.1
defaultSearchBase: dc=test,dc=oss
authenticationMethod: simple
followReferrals: FALSE
defaultSearchScope: sub
searchTimeLimit: 30
profileTTL: 43200
bindTimeLimit: 10
cn: automount_profile
credentialLevel: proxy
serviceSearchDescriptor: passwd: ou=People,dc=test,dc=oss?one
serviceSearchDescriptor: group: ou=group,dc=test,dc=oss?one
serviceSearchDescriptor: shadow: ou=People,dc=test,dc=oss?one
serviceSearchDescriptor: netgroup: ou=netgroup,dc=test,dc=oss?one
serviceSearchDescriptor: auto.master: nisMapName=auto.master,dc=test,dc=oss?one
serviceSearchDescriptor: auto.home: nisMapName=auto.home,dc=test,dc=oss?one
serviceSearchDescriptor: auto_master: automountMapName=auto_master,dc=test,dc=oss?one
serviceSearchDescriptor: auto_home: automountMapName=auto_home,dc=test,dc=oss?one
serviceSearchDescriptor: auto_direct: automountMapName=auto_direct,dc=test,dc=oss?one
objectclassMap: automount: automount=nisObject
objectclassMap: automount: automountMap=nisMap
attributeMap: automount: automountInformation=nisMapEntry
attributeMap: automount: automountKey=cn
attributeMap: automount: automountMapName=nisMapName

Ez gyakorlatilag minden olyan definíciót tartalmaz, amit manuálisan felsoroltam.

LDAP kliens inicializálása

Akkor nézzük, ha már van egy profilunk (természetesen több is lehet, más-más néven), akkor azt hogyan is tudjuk felhasználni a kliensünk esetében, mennyivel egyszerűsödik az inicializálás.

kliens# ldapclient -v init -a profileName=automount_profile -a domainName=test.oss -a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=oss -a proxyPassword=ossproxy 192.168.132.1

Ahogy az látszik, csupán egy proxy felhasználót adtam meg, illetve annak jelszavat, plusz a profil nevet. Nem DN-jet, csak a nevet. Az LDAP client tudja, jól, hogy a profile Organization Unit alatt keresse azt, az LDAP serveren.

Ezek után egyszerűen tudunk klienseket a meglévő LDAP szerverünkhöz integrálni.

Mit akarunk elérni?

Tehát eddig, ha egy új servert installáltunk, elég volt az LDAP klienst inicializálni az LDAP serverünkhöz, és már a felhasználóink lépkedhettek is be. A felhasználóknak viszont manuálisan a serveren kell létrehoznunk a home könyvtárát. Amennyiben viszont használjuk az automount funkciót, úgy egy távoli szerverről automatikusan felmountolhatjuk a felhasználók (vagy épp más könyvtár) home könyvtárát.

Ehhez egész egyszerűen, csak azt kell tennünk, hogy a serverünkön a megfelelő konfigurációs file-t megszerkesztjük. Viszont miért akarjunk ezzel küzdeni, ha ezt az információt is tárolhatjuk LDAP-ban? Így az LDAP inicializálása után, máris automatikusan minden felhasználó elérhető lesz, saját NFS mountolt home könyvtárral.

Automount séma

Én most kiindulási alapnak az előző cikkben felvázolt állapotot tekintem. Természetesen az automount kezelésért felelős objektumokhoz egy új sémát is hozzá kell adnunk:

# vi
.....
include /usr/local/etc/openldap/schema/automount.schema
.....

Az automount.schema file nem standard, ezt magunknak kell létrehoznunk. Íme a file tartalma:

# cat /usr/local/etc/openldap/schema/automount.schema
attributetype ( 1.3.6.1.1.1.1.33
NAME 'automountInformation'
DESC 'automount information'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'user defined' )

attributetype ( 1.3.6.1.1.1.1.31
NAME 'automountMapName'
DESC 'automount Map Name'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'user defined' )

attributetype ( 1.3.6.1.1.1.1.32
NAME 'automountKey'
DESC 'automount Key Value'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'user defined' )

objectclass ( 1.3.6.1.1.1.2.16
NAME 'automountMap'
SUP top
STRUCTURAL
MUST automountMapName
MAY ( description $ ou )
X-ORIGIN 'user defined' )

objectclass ( 1.3.6.1.1.1.2.17
NAME 'automount'
SUP top
STRUCTURAL
MUST ( automountInformation $ automountKey )
MAY ( cn $ description )
X-ORIGIN 'user defined' )

Ezek után indítsuk újra a SLDAP-ot. Ezzel fognak ugyanis csak érvényesülni az új beállítások.

Automount struktúra létrehozása

A következőkben már csak LDAP-ban kell létrehoznunk a tényleges bejegyzéseket, amikben az automount információkat akarjuk kezelni.

Én a következő objektumokat hoztam létre, ezeket tartalmazza az automount.ldif:

# cat automount.ldif
dn: ou=automount,dc=test,dc=oss
ou: automount
objectClass: top
objectClass: organizationalUnit

dn: nisMapName=auto.master,dc=test,dc=oss
objectClass: top
objectClass: nisMap
nisMapName: auto.master

dn: cn=/home,nisMapName=auto.master,dc=test,dc=oss
objectClass: top
objectClass: nisObject
cn: /home
nisMapEntry: ldap:nisMapName=auto.home,dc=test,dc=oss
nisMapName: auto.master

dn: nisMapName=auto.home,dc=test,dc=oss
objectClass: top
objectClass: nisMap
nisMapName: auto.home

dn: cn=/,nisMapName=auto.home,dc=test,dc=oss
objectClass: top
objectClass: nisObject
cn: /
nisMapEntry: 192.168.132.1:/store/home/&
nisMapName:auto.home

dn: automountMapName=auto_master,dc=test,dc=oss
objectClass: top
objectClass: automountMap
automountMapName: auto_master
ou: auto_master

dn: automountkey=/home,automountMapName=auto_master,dc=test,dc=oss
objectClass: top
objectClass: automount
automountKey: /home
cn: /home
automountInformation: auto_home -nobrowse

dn: automountKey=/-,automountMapName=auto_master,dc=test,dc=oss
objectClass: top
objectClass: automount
automountKey: /-
cn: /-
automountInformation: auto_direct

dn: automountMapName=auto_home,dc=test,dc=oss
objectClass: top
objectClass: automountMap
automountMapName: auto_home
ou: auto_home

dn: automountKey=*,automountMapName=auto_home,dc=test,dc=oss
objectClass: top
objectClass: automount
automountKey: *
cn: *
automountInformation: 192.168.132.1:/store/home/&

dn: automountMapName=auto_direct,dc=test,dc=oss
objectClass: top
objectClass: automountMap
automountMapName: auto_direct
ou: auto_direct

Akkor adjuk is hozzá:

# ldapadd -D "cn=diradmin,dc=test,dc=oss" -w osssecret -f /tmp/openldap_install/ldifs/automount.ldif

Jól ki lehet venni az automount alap struktúráját, de nézzük, hogy néz ez ki grafikusan:

A képen továbbá az is látszik, hogy az auto_home objektum alá létrehoztam egy "csillag" recordot, amibe egy nfs share van definiálva úgy, hogy a "&" jel helyettesítse mindig a felhasználónevet.

Ezzel kész is vagyunk LDAP server oldalról. Már csak a megfelelő sharekről kell gondoskodnunk.

Solaris Kliens inicializálása auto_home-val

Nem sokat változik a parancs, további attributumokat kell megadnunk csupán, arra vonatkozóan, hogy az automount információk, hol találhatóak.

#ldapclient manual -v
-a credentialLevel=proxy
-a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=oss
-a proxyPassword=ossproxy
-a defaultSearchBase=dc=test,dc=oss
-a defaultSearchScope=sub
-a domainName=test.oss
-a serviceSearchDescriptor=passwd:dc=test,dc=oss?sub
-a serviceSearchDescriptor=shadow:dc=test,dc=oss?sub
-a serviceSearchDescriptor=group:dc=test,dc=oss?sub
-a serviceAuthenticationMethod=pam_ldap:simple
-a authenticationMethod=simple
-a attributeMap=automount:automountKey=cn
-a attributeMap=automount:automountInformation=nisMapEntry
-a attributeMap=automount:automountMapName=nisMapName
-a serviceSearchDescriptor=auto_master:automountMapName= auto_master,dc=test,dc=oss?sub
-a serviceSearchDescriptor=auto_home:automountMapName= auto_home,dc=test,dc=oss?sub
192.168.132.1

Működés közben

Ha minden megvan, és nem tapasztaltunk hibát, akkor jöhet a teszt. Először is nézzük milyen a rendszer mielőtt belépnénk egy LDAP userrel:

# w
# df -h

Majd miután beléptünk egy LDAP userrel:
# w
# df -h

Ahogy kell automatikusan felcsatolta az LDAP-ban meghatározott share-t a felhasználóhoz. Így könnyen, gyorsan tudunk egy serveren felhasználókat konfigurálni, és a hozzájuk tartozó tárhelyeket is. A server újrainstallálása esetén se történik a felhasználók adataival semmi.

Sok mindenről beszélhetnék Frankfurt kapcsán, én mégis a számomra léglenyűgözővel kezdeném, a felhőkarcolókkal. A város szíve a pénztől roskadozik, ezt pedig jól szimbolizálják a hihetetlen gyönyörű, és égig érő épületei. Szinten minden ilyen épület valami pénzintézettel kapcsolatos. A felhőkarcolók mellett, között viszont gyönyörű parkok, és széles utak kapnak helyett, ami még inkább növeli a környék nagyságát és pompáját.

Fontos még kiemelnem a Main folyót. Budapesthez hasonlóan a nagy várost is kettészeli egy széles folyó. Itt viszont hosszan a parton zöld része vannak kialakítva. Itt rendszeres az esti élet. Az emberek, kortól, öltözéktől függetlenül kimennek a folyó mellé és beszélgetnek iszogatnak. Megdöbbentő volt látni, ahogy a fiatalok, a nyakkendős üzletemberek, punkok, discosok, mind-mind ott voltak, és jól érezték magukat. Ingyen.

Ami otthon nem valósulhat meg itt helyet kapott, és talán a legjobb példa a sok-sok gyaloghíd. Olyan hidak, amiken csak gyalogos, biciklis közlekedés folyhat. Hihetetlen de igen. Frankfurtban, ahogy sok más német városban hihetetlen nagy kultúrája van a mozgásnak.

Bár továbbra is München a kedvenc német városom, de Frankfurt most odakúszott ezzel a kirándulással a második helyre. Az összes kép, amit készítettünk megtekinthető itt.

LDAP

Ez egy rövidítés. Lightweight Directory Access Protocol azaz "pehelykönnyű könyvtár hozzáférés protokoll". Egyszerűen mondva egy olyan fa struktúrán alapuló adatbázis ahol tipikusan gyorsan kell keresnünk, és sok kis információt akarunk benne elraktározni. Íme egy kis ábra arról a filozófiáról amit az LDAP vall:

Jól látszik a fa struktúra. Fent van a gyökér elem (ahonnan a fa kinő ez a kezdő pont). Minden zöld elemnek kell hogy legyen Distinguished Name-je (rövidítve DN), azaz egyedi megkülönböztető neve, amivel hivatkozhatunk rá.

Ezek a DN-ek tartalmazhatnak minden féle rövidítési tagot. A fenti példában is jól látszik ahogy "dc=", "cn=" értékekkel nevesítsük a levél elemeket. Ahhoz hogy egy levélelemet meg akarunk hivatkozni, akkor a teljes DN-jét meg kell adnunk. A fenti példában például: "uid=anne, cn=users, dc=example, dc=com" DN-el hivatkozzuk meg Anne Johnson bejegyzését. Lehetőségünk van relative distinguished name (rövidítve RDN) megadására is, amikor nem a gyökérelemhez viszonyítva adjuk meg a helyzét a másik elemnek.

Az LDAP tehát egy gyorsan kereshető címtár. Ahol strukturáltan tudunk információkat tárolni. Itt tárolódnak majd a számítógépeink minden kapcsolódó információval együtt, a felhasználóink csoportjaink. Az LDAP jól ismert a Linux/UNIX világban, és természetesen lehetőség van bármely olyan a külső alkalmazással használni ami a normál LDAP standard kapcsolódást támogat.

Előkészületek

A következő leírásban egy Solaris 10 operációs rendszerre fogok installálni OpenLDAP servert. Felépítek benne egy kis egyszerű struktúrát, egy User csoportal és egy testuser felhasználóval. Ezek után inicializálni fogom a Solaris 10-ben lévő ldap klienst, és ezáltal lehetővé teszem, hogy az LDAP-ban tárolt felhasználó és csoport információk alapján egyszerűen lehessen felhasználókat managelni központosítva. A folyamat közben, az egyszerűbb szemléltés végett egy LDAP klienst is fogok használni. Ez távolról képes csatlakozni az LDAP server-hez, és arról vizuálisabb adatokat képes szolgáltatni. Amennyiben úgy állítottuk be az LDAP serverünket (ACL), akkor LDAP kliensen keresztül lehetőségünk van törölni, létrehozni, módosítani. Bár több ilyen kliens is létezik, én legjobbnak a Softerra LDAP Administrator termékét találtam.

OpenLDAP installáció

Én a következőkben nem fogom forrásból fordítani az OpenLDAP-ot, bár lehetne. A SunFreeware oldaláról szedett csomagokkal fogok dolgozni.

Ha már a gépünkön van, akkor szépen rakjuk fel az összes komponenst.

# cd /tmp/openldap_install
# ls -lah
# gunzip *.gz

# pkgadd -d db-4.7.25.NC-sol10-sparc-local
# pkgadd -d libtool-2.2.6b-sol10-sparc-local
# pkgadd -d sasl-2.1.21-sol10-sparc-local
# pkgadd -d libgcc-3.4.6-sol10-sparc-local
# pkgadd -d openssl-1.0.0a-sol10-sparc-local
# pkgadd -d openldap-2.4.22-sol10-sparc-local

Konfiguráció

A konfigurációs file-t következőképp szerkesszük meg, ehhez a solaris.schema file-ra külön szükségünk lesz. Ezt alapból az OpenLDAP nem fogja tartalmazni.

# mv /export/home/miszterx/solaris.schema /usr/local/etc/openldap/schema/
# ls -lah /usr/local/etc/openldap/schema/

Akkor most nézzük, hogy is néz ki a config:

# cat /usr/local/etc/openldap/slapd.conf

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/duaconf.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
include /usr/local/etc/openldap/schema/solaris.schema

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args

# ACL's
access to dn.subtree="ou=People,dc=test,dc=oss" attrs=userPassword,shadowLastChange
by dn="cn=proxyagent,ou=profile,dc=test,dc=oss" write
by self write
by anonymous auth
by * read

# Do not allow users so change their uid/gid/groupmembership
access to attrs=uid,uidNumber,gidNumber,memberUid
by * read

access to dn.base=""
by dn="cn=proxyagent,ou=profile,dc=test,dc=oss" read
by * read

access to dn.base="cn=Subschema"
by anonymous none
by * read

access to dn.subtree="ou=People,dc=test,dc=oss"
by self write
by * read

access to dn.subtree="ou=Group,dc=test,dc=oss"
by * read

access to *
by * read

###############################################
# BDB database definitions
###############################################

database bdb
suffix "dc=test,dc=oss"
rootdn "cn=diradmin,dc=test,dc=oss"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw osssecret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
# Indices to maintain
index objectClass eq

Indítsuk el az LDAP servert a következő paranccsal:

# /usr/local/libexec/slapd

Ha nem jelenne meg a process, akkor nem sikerült elindulnia. Ebben az esetben érdemes debug módban elindítani, ahol láthatjuk, hogy mi a baj:

# /usr/local/libexec/slapd -d 500

Első induláskor nekem a következő hibába sikerült rendszeresen belefutnom:

Itt az LDAP által használt gráf típusú BDB adatbázissal van gond. Ezt egy Berkeley DB-t jelent a mi esetünkben. Egyszerűen futtassunk rajta egy visszaállítást, és ez megoldja a gondjainkat.

# cd /usr/local/var/openldap-data/
# /usr/local/BerkeleyDB.4.7/bin/db_recover

Érdemes még ennek a DB_CONFIG-ját is létrehozni. Mostani esetben bőven elég ha a példa file-t átnevezzük:

# mv /usr/local/var/openldap-data/DB_CONFIG.example /usr/local/var/openldap-data/DB_CONFIG

Ezek után már debug módban azt kell látnunk, hogy gond nélkül elindult az LDAP:

# /usr/local/libexec/slapd -d 500

Ha így lenne, akkor már indíthatjuk sima háttérbe futó deamonként így:

# /usr/local/libexec/slapd
# ps -ef | grep slapd

Adatok feltöltése

Most már fut az LDAP server lehetőségünk van csatlakozni hozzá. Nézzünk is egy keresést:

# ldapsearch -x -b 'dc=test,dc=oss' -D "cn=diradmin,dc=test,dc=oss" '(objectclass=*)' -W

LDAP Administratorban ugyan ez:

Nem meglepő, hogy azt kapjuk, hogy No such object. Ugyanis az LDAP server fut, de még nem adtunk semmilyen struktúrát, recordot neki.

Én szépen sorjában, külön külön LDIF file-ket fogok csinálni, és ezeket adom hozzá. Így jobban látszik majd, hogy épül fel. Először adjuk hozzá a gyökérelemet:

# cat init.ldif
dn: dc=test,dc=oss
associatedDomain: test.oss
objectClass: top
objectClass: dcObject
objectClass: domain
objectClass: domainRelatedObject
objectClass: nisDomainObject
nisDomain: test.oss
o: Organisation Name

Akkor ezt most adjuk hozzá:
ldapadd -D "cn=diradmin,dc=test,dc=oss" -w osssecret -f /export/home/miszterx/init.ldif

Nézzük ezzel mit értünk:

# ldapsearch -x -b 'dc=test,dc=oss' -D "cn=diradmin,dc=test,dc=oss" '(objectclass=*)' -W

LDAP Administratorban ugyan ez:

Most jöjjön a felhasználók csoport eleme a People, és a csoportok eleme a Group létrehozása:

# cat people_groups.ldif
dn: ou=People, dc=test,dc=oss
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group, dc=test,dc=oss
ou: Group
objectClass: top
objectClass: organizationalUnit

Most adjuk hozzá:
# ldapadd -D "cn=diradmin,dc=test,dc=oss" -w osssecret -f /export/home/miszterx/people_groups.ldif

Nézzük akkor most hogy is állunk, ez már kicsit látványosabb lesz:
# ldapsearch -x -b 'dc=test,dc=oss' -D "cn=diradmin,dc=test,dc=oss" '(objectclass=*)' -W

LDAP Administratorban ugyan ez:

Most hozzunk létre egy profile elemet, majd ez alá egy proxyagent felhasználót. Őt fogjuk használni a kliensek esetében, ahhoz hogy a megfelelő adatokhoz hozzáférhessünk. Ehhez a felhasználóhoz adtunk a configban speciális ACL-eket.

# cat proxy.ldif
dn: ou=profile, dc=test,dc=oss
ou: profile
objectClass: top
objectClass: organizationalUnit

dn: cn=proxyagent,ou=profile, dc=test,dc=oss
userPassword: ossproxy
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent

Most adjuk hozzá:
# ldapadd -D "cn=diradmin,dc=test,dc=oss" -w osssecret -f /export/home/miszterx/proxy.ldif

LDAP Administratorban ugyan ez:

Most pedig hozzuk létre az első felhasználónkat:

# cat testuser.ldif
dn: uid=testuser,ou=People, dc=test,dc=oss
shadowMin: 5
sn: User
userPassword: test
loginShell: /bin/bash
uidNumber: 9999
gidNumber: 1000
shadowFlag: 0
shadowExpire: -1
shadowMax: 99999
uid: testuser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
gecos: Test User
shadowLastChange: 0
cn: Test User
homeDirectory: /export/home/testuser
shadowInactive: -1
shadowWarning: 7

Adjuk hozzá:
# ldapadd -D "cn=diradmin,dc=test,dc=oss" -w osssecret -f /export/home/miszterx/testuser.ldif

LDAP Administratorban ugyan ez:

Kliens LDAP inicializálása

Felépítettük a struktúránkat, most már csak a felhasználó adatokat jó lenne ha a kliensek is használnák. Ehhez inicializálnunk kell a beépített Solaris 10 ldap service-t.

Alap esetben:
# svcs ldap/client

Akkor jöjjön a mágikus parancs:
# ldapclient manual -v -a credentialLevel=proxy
-a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=oss
-a proxyPassword=osssecret
-a defaultSearchBase=dc=test,dc=oss
-a defaultSearchScope=sub
-a domainName=test.oss
-a serviceSearchDescriptor=passwd:dc=test,dc=oss?sub
-a serviceSearchDescriptor=shadow:dc=test,dc=oss?sub
-a serviceSearchDescriptor=group:dc=test,dc=oss?sub
-a serviceAuthenticationMethod=pam_ldap:simple
-a authenticationMethod=simple 10.0.0.13

És jobb esetben a serivce is online lesz:
# svcs ldap/client

Nézzük mit értünk el ezzel. Kérjük le gép számára elérhető usereket:

# getent passwd

Szuper megjelent a rendszerünk számára a definiált testuser. Akkor próbáljunk belépni vele.

masik-host# ssh testuser@10.0.0.10

Nem megy. Nem fogadja el a jelszót. Viszont a service online, az inicializálás hiba nélkül ment. Akkor csak egy helyen lehet a probléma. Méghozzá a jelszó értelmezésében. Most plaintext módon tároljuk az UserPassword a értékét. Ezzel nem is lenne gond, mert az LDAP simple bind-el tudja használni, de a Solaris a user password-höz titkosított jelszót használ.

Tehát nekünk titkosítottan kell tárolnunk a jelszót az LDAP-ban az usereinkhez. A Solaris alapból DES alapú crypt algoritmust használ. Több féle módon is kreálhatunk ilyen jelszavakat, én most a legegyszerűbb módszert fogom megmutatni, amit az LDAP Administrator támogat:

Ezek után válogathatunk a titkosító algoritmusok között, viszont nekünk a DES(Crypt) kell.

Ha ez megvan máris hasonló dolgot kell látnunk:

Ezek után pedig már sikeresen beléphetünk a megfelelő LDAP felhasználóval.

Milyen információkra lesz szükségünk?

Mielőtt még a Linuxunkhoz nyúlnánk, vegyük szépen sorba milyen információkra lesz szükségünk a kezdéshez.

- Mac Os X Serverünk Open Directory-jának IP címe vagy host neve.
- Mac Os X Serverünk Open Directory-jának a Search Base DN-jére. Az én esetemben ez most dc=earth,dc=xorp,dc=hu lesz.
- Mac Os X Serverünk Open Directory-jának egy felhasználójának a DN-jére. Akármelyik felhasználó megtenné, de mivel valószínüleg fixen mindenkinél van diradmin, azért én ezt fogom használni. Az alapértelmezett DN-je a diradminnak nálam: uid=diradmin,cn=users,dc=earth,dc=xorp,dc=hu
- Mac Os X Serverünk Open Directory felhasználójának jelszava.

Előkészületek

Én a következőket egy Ubuntu 10.04-es rendszeren fogom szemléltetni. Természetesen akár milyen más Linuxon is érvényesek lesznek a beállítások, csupán a következő parancstól eltérően kell gondoskodni az installációról.

# apt-get install libpam-ldap libnss-ldap nss-updatedb

Amennyiben minden gond nélkül felinstallálódik, kezdhetjük is a konfigurációt.

LDAP beállítása

Ubuntu 10.04 alatt szerencsénkre a csomagok felkerülésével egyszerre a megfelelő rendszer file-k is módosultak, méghozzá úgy, hogy alkalmazzák majd a beállított LDAP információkat. Ha ellenőrizni szeretnénk, vagy nem Ubuntu-val dolgozunk, és ez nem történik meg automatikusan, akkor a következő file-ket szerkesszük meg:

# cat /etc/nsswitch.conf

# cat /etc/pam.d/common-account

# cat /etc/pam.d/common-auth

# cat /etc/pam.d/common-password

# cat /etc/pam.d/common-session

LDAP Kliens konfigurálása

Ha már a rendszerünket teljesen felkészítettük az LDAP által szolgáltatott információkra, akkor nincs más, mint magát az LDAP klienst is beállítani. Ehhez fogjuk azon információkat felhasználni, amiket az írás elején összegyűjtöttünk. Azok alapján az én konfigom így néz ki (kilistáztam a nem kikommentezett vagy üres sorokat):

# cat /etc/ldap.conf |grep -v "#" | grep -v "^$"

base dc=earth,dc=xorp,dc=hu
uri ldap://10.0.0.2
ldap_version 3
rootbinddn uid=diradmin,cn=users,dc=earth,dc=xorp,dc=hu
pam_password md5
nss_initgroups_ignoreusers backup, bin, daemon, games, gnats, irc, landscape, libuuid, list, lp, mail, man, news, proxy, root, sshd, sync, sys, syslog, uucp, www-data

A rootbinddn-hez tartozó jelszót a /etc/ldap.secret file tartalmazza. A Mac OS X Open Directory MD5 titkosítással őrzi a jelszavakat, fontos hogy az legyen a konfigunkba is beállítva.

Teszt

Érdemes ezek után kiadni a következő parancsot:

# getent passwd

Ha minden jól van beállítva hasonló tartalmat kell látnunk, mintha csak az /etc/passwd file tartalmát listáztuk volna, viszont a sor végén a Open Directory által tártolt felhasználók is meg fognak jelenni.

Ez már azt jelenti, hogy felhasználó adatokat már tud a gépünk lekérni a központi LDAP-tól, de a végső próba az, ha egy ilyen felhasználóval ssh-zni próbálunk.

# ssh ldaptestuser@localhost

Természetesen az ldaptestuser akármi lehet, ami az Open Directory-ban létezik. Ha ez is működött, akkor elértük a célunkat. Sajnos ez a most demonstrált megoldás nem nyújt biztonságot arra az esetre, ha a Open Directory elérhetetlenné válna egy kis időre. Ezen idő alatt a központi LDAP-ban tárolt felhasználók elérhetetlenek lesznek. Tehát nincs semmi cachelés, mint a Mac OS X, vagy Solaris 10 esetében.

Kapcsoljuk ki a grafikus felületet, amennyiben nem használjuk

A leggyakoribb esetben Solaris csak és kizárólag kiszolgálói funkciót lát el. Ehhez viszont a legkevésbé sem szükséges számunkra a grafikus felületet futtatnunk. Az Oracle, és egyéb programok igénylik majd, tehát nem tehetjük meg, hogy nem is telepítjük, viszont ha nem muszáj ne használjuk.

# ps -efl

Ahogy látszik fut az X server, és a hozzá tartozó process-ek. Ahhoz, hogy kiiktassuk elegendő a CDE (Common Desktop Environment) Serviceket kikapcsolni.

# svcs -a|grep cde
# svcadm disable cde-calendar-manager
# svcadm disable cde-ttdbserver
# svcadm disable cde-printinfo
# svcadm disable cde-login
# svcs -a|grep cde

Ezek után természetesen a konzolunkon is megjelenik az egyszerű szöveges üzemmód:

Illetve a process listából is eltűnt néhány tag:
# ps -efl

Természetesen ha X-re lenne szükségünk, tudjuk használni az xhost parancsot, illetve, másik X serverre át tudjuk irányítani ezen server grafikus dolgait ha szükséges.

A Solaris 10 tartalmaz egy web console-t. Ezen lehet minden féle alkalmazás managementjét beregisztrálva, szépen és okosan, kattingatva csinálni minden félét. Sajnos elég erőforrás igényes, és sok esetben felesleges is, így ha csak nincs okunk rá, hogy fusson kapcsoljuk ki.

# svcs webconsole
# svcadm disable webconsole

El is tűnt a process listából a java alkalmazás, ami annyi memóriát evett:

# ps -efl

Kapcsoljuk ki a felesleges inetd folyamatokat

# inetadm

Amennyiben van felesleges folyamat, ami engedélyezve van azt így tudjuk disable-re tenni:

# inetadm -d [process-neve]

Amennyiben pedig mégis engedélyezni szeretnénk valamit akkor:

# inetadm -d [process-neve]

Ellenőrizzük, hogy milyen portok vannak nyitva a gépen

Ezt meg tehetjük belülről is:

# netstat -an |grep -i listen

Illetve kívülről, egy portscan segítségével. Én most nmap-ot fogok használni:
# /usr/local/bin/nmap -sT 10.0.0.10

Amennyiben tapasztalunk feleslegesen nyitott portot, akkor nekiállhatunk nyomozni mi is használja azt a portot.

Itt egy kis script arra, hogy tudjuk kideríteni melyik process fogja azt a portot:

#!/bin/sh

if [ `/usr/xpg4/bin/id -u` -ne 0 ]; then
echo "ERROR: This script must run as root to access pfiles command."
exit 1
fi

if [ $# -eq 1 ]; then
port=$1
else
printf "which port?> "
read port
echo "Searching for processes using port $port...";
echo
fi

for pid in `ps -ef -o pid | tail +2`
do
foundport=`/usr/proc/bin/pfiles $pid 2>&1 | grep "sockname:" | egrep "port: $port$"`
if [ "$foundport" != "" ];
then
echo "proc: $pid, $foundport"
fi
done

exit 0

Íme, ahogy működik:

./port_tester.sh
which port?> [ITT ADJUK MEG A PORTOT]

SNMP agent kikapcsolása

Amennyiben futna az SNMP agent, úgy érdemes kikapcsolni, ha nem használnánk a gépünk monitorozására a servicet. Amennyiben mégis, bizonyosodjuk meg róla, hogy legalább nem a private és public kulcsszavakat állítottuk be.

# svcs snmpdx

Amennyiben működnie is kellene, akkor a következő konfigurációs állományokat érdemes ellenőrizni:

/etc/snmp/conf/snmpd.conf
/etc/snmp/conf/snmpdx.acl
/etc/sma/snmp/snmpd.conf

SSH beállítások ellenőrzése

Valószínűleg szinte mindenki használ ssh kapcsolatot a serverével. Itt is érdemes figyelni pár alapvető beállításra.

Először is, bizonyosodjunk meg róla, hogy A root bejelentkezése nincs engedélyezve:

# cat /etc/ssh/sshd_config |grep -i permitroot

Másod sorban bizonyosodjunk meg arról, hogy csak a kettes protokollt hajlandó kezelni az SSH deamonünk, az elavult egyeset nem:

# cat /etc/ssh/sshd_config |grep -i protocol

Seccheck - Biztonsági ellenörzés automatikus scriptekkel

Természetesen Solaris-ra is létezik olyan tool, ami átfésüli a rendszerünket, és arról minden féle reportot generál. Én ezt a SunFreeware oldalról szereztem be a csomagot, amúgy hivatalos oldal itt.

A csomagot a szokott módon telepíthetjük:
# gunzip seccheck-0.7.6-sol10-x86-local.gz
# pkgadd -d /tmp/seccheck-0.7.6-sol10-x86-local

Ahogy írtam ez nem is igazi program, csupán egy script gyűjtemény. Modulokból áll, és minden modul más más dolgokat ellenőriz:
# cd /usr/local/seccheck/bin/modules.d/
# ls -lah

Nézzük, hogy is tudjuk elindítani az ellenörzést, és hogyan fut:

# cd /usr/local/seccheck/bin/
# ./seccheck.sh

A következő ellenőrzések fognak lefutni:
[ Checking Services ]
[ Checking RPC Services ]
[ Checking NIS/NIS+ Services ]
[ Checking LDAP Services ]
[ Checking Kerberos/GSS Services ]
[ Checking if dtlogin is running ]
[ Checking Solaris Management Console services ]
[ Checking volmgt Services ]
[ Checking SAMBA Services ]
[ Checking NFS Services ]
[ Checking Automount Services ]
[ Checking Telnet Service ]
[ Checking FTP Service ]
[ Checking Boot Services ]
[ Checking DHCP Service ]
[ Checking DNS Service ]
[ Checking TFTP Service ]
[ Checking Print Services ]
[ Checking Web Services ]
[ Checking SNMP Service ]
[ Checking INETD ]
[ Checking System Accounts ]
[ Checking for Accounts With Empty Passwords ]
[ Checking for Legacy "+" Entries in passwd Files ]
[ Checking for UID 0 Accounts ]
[ Checking UMASK and mesg Settings ]
[ Checking "coreadm" Configuration ]
[ Checking Stack Protection ]
[ Checking NFS Priviledged Port Restrictions ]
[ Checking TCP Sequence Numbers ]
[ Checking Network Parameters ]
[ Checking inetd Tracing ]
[ Checking FTP Logging ]
[ Checking Connection Logging ]
[ Checking syslog AUTH Logging ]
[ Checking logging of failed login attempts ]
[ Checking cron logging ]
[ Checking System Accounting ]
[ Checking System Log File Permissions ]
[ Checking for "login:" Prompts on Serial Ports ]
[ Checking "nobody" Access for Secure RPC ]
[ Checking SSH Daemon Configuration ]
[ Checking for .rhosts Support in /etc/pam.conf ]
[ Checking /etc/ftpd/ftpusers ]
[ Checking That sendmail Only Listens Locally ]
[ Checking That syslogd Will Not Accept Remote Messages ]
[ Checking That TCP Wrappers is Enabled ]
[ Checking crontabs ]
[ Checking cron Facility Access ]
[ Checking That root Can Only Log in on /dev/console ]
[ Checking Account Lockout Policy ]
[ Checking Daemon umask ]
[ Checking rmmount.conf ]
[ Checking passwd Files ]
[ Checking World Writable Directories For Sticky Bit ]
[ Checking for World Writable Files ]
[ Checking for SUID/SGID System Executables ]
[ Checking for Unowned Files and Directories ]
[ Checking for Extended Attributes ]

Alap esetben a kiértékelés eredményét, és a hibákra való javaslatot a képernyőn látjuk, ámbár lehetőségünk van egy könyvtár definiálásával egy file-ba irányítani azt:

# ./seccheck.sh -o ../output/

Ahogy az látszani fog, a tool ahol hibát talál, javaslatot is tesz arra, hogyan javítsuk azt. Ezáltal teljes mértékben meg tudjuk "erősíteni" (hardening) a rendszerünket.

# cat ../output/seccheck-test-20100713-1235.log |more
=====================================================
SCAN STARTED: Tue Jul 13 12:35:58 CEST 2010
=====================================================
[ SECCHECK - Checking all Modules in modules.d ]
=====================================================
=====================================================
[ Checking Services ]
=====================================================
OK: No questionable services found
=====================================================
[ Checking RPC Services ]
=====================================================
WARNING: Service "svc:/network/rpc/bind:default" is [online]
INFO: The following online services are dependent on this service:
online svc:/system/sysidtool:system
online svc:/system/filesystem/autofs:default
online svc:/network/inetd:default
online svc:/network/rpc/gss:default
online svc:/network/rpc/smserver:default
online svc:/system/filesystem/volfs:default
online svc:/system/fmd:default
online svc:/milestone/multi-user:default
INFO: Checking svc:/network/rcp/bind:default for tcpwrappers support
WARNING: svc:/network/rpc/bind:default tcpwrappers support is not enabled
INFO: Consider enabling tcpwrappers support with the following commands:
INFO: /usr/sbin/svccfg -s rpc/bind setprop config/enable_tcpwrappers = true
INFO: /usr/sbin/svcadm refresh rpc/bind
OK: Service "svc:/network/rpc/keyserv:default" is disabled
=====================================================
[ Checking NIS/NIS+ Services ]
=====================================================
OK: All NIS/NIS+ related services disabled
=====================================================
[ Checking LDAP Services ]
=====================================================
OK: LDAP cache manager is disabled
=====================================================
[ Checking Kerberos/GSS Services ]
=====================================================
WARNING: Service "svc:/network/security/ktkt_warn:default" is [online]
WARNING: Service "svc:/network/rpc/gss:default" is [online]
=====================================================
[ Checking if dtlogin is running ]
=====================================================
OK: svc:/network/rpc-100083_1/rpc_tcp:default is not present
OK: dtlogin is not set to start in runlevel 2
=====================================================
[ Checking Solaris Management Console services ]
=====================================================
OK: wbems not set to start in runlevel 2
OK: dtlogin is not set to start in runlevel 2
=====================================================
bash-3.00# cat ../output/seccheck-test-20100713-1235.log
=====================================================
SCAN STARTED: Tue Jul 13 12:35:58 CEST 2010
=====================================================
[ SECCHECK - Checking all Modules in modules.d ]
=====================================================
=====================================================
[ Checking Services ]
=====================================================
OK: No questionable services found
=====================================================
[ Checking RPC Services ]
=====================================================
WARNING: Service "svc:/network/rpc/bind:default" is [online]
INFO: The following online services are dependent on this service:
online svc:/system/sysidtool:system
online svc:/system/filesystem/autofs:default
online svc:/network/inetd:default
online svc:/network/rpc/gss:default
online svc:/network/rpc/smserver:default
online svc:/system/filesystem/volfs:default
online svc:/system/fmd:default
online svc:/milestone/multi-user:default
INFO: Checking svc:/network/rcp/bind:default for tcpwrappers support
WARNING: svc:/network/rpc/bind:default tcpwrappers support is not enabled
INFO: Consider enabling tcpwrappers support with the following commands:
INFO: /usr/sbin/svccfg -s rpc/bind setprop config/enable_tcpwrappers = true
INFO: /usr/sbin/svcadm refresh rpc/bind
OK: Service "svc:/network/rpc/keyserv:default" is disabled
=====================================================
[ Checking NIS/NIS+ Services ]
=====================================================
OK: All NIS/NIS+ related services disabled
=====================================================
[ Checking LDAP Services ]
=====================================================
OK: LDAP cache manager is disabled
=====================================================
[ Checking Kerberos/GSS Services ]
=====================================================
WARNING: Service "svc:/network/security/ktkt_warn:default" is [online]
WARNING: Service "svc:/network/rpc/gss:default" is [online]
=====================================================
[ Checking if dtlogin is running ]
=====================================================
OK: svc:/network/rpc-100083_1/rpc_tcp:default is not present
OK: dtlogin is not set to start in runlevel 2
=====================================================
[ Checking Solaris Management Console services ]
=====================================================
OK: wbems not set to start in runlevel 2
OK: dtlogin is not set to start in runlevel 2
=====================================================
[ Checking volmgt Services ]
=====================================================
WARNING: Service "svc:/network/rpc/smserver:default" is [online]
=====================================================
[ Checking SAMBA Services ]
=====================================================
OK: samba not set to start in runlevel 3
=====================================================
[ Checking NFS Services ]
=====================================================
OK: All NFS related services disabled
=====================================================
[ Checking Automount Services ]
=====================================================
WARNING: Service "svc:/system/filesystem/autofs:default" is [online]
=====================================================
[ Checking Telnet Service ]
=====================================================
OK: Service "svc:/network/telnet:default" is disabled
=====================================================
[ Checking FTP Service ]
=====================================================
OK: Service "svc:/network/ftp:default" is disabled
=====================================================
[ Checking Boot Services ]
=====================================================
OK: All Boot services are disabled
=====================================================
[ Checking DHCP Service ]
=====================================================
OK: Service "svc:/network/dhcp-server:default" is disabled
=====================================================
[ Checking DNS Service ]
=====================================================
OK: Service "svc:/network/dns/server:default" is disabled
=====================================================
[ Checking TFTP Service ]
=====================================================
OK: No TFTP Services Installed
=====================================================
[ Checking Print Services ]
=====================================================
OK: All Print Services are disabled
=====================================================
[ Checking Web Services ]
=====================================================
OK: Service "svc:/network/http:apache2" is disabled
WARNING: apache is set to start in runlevel 3
INFO: mv /etc/rc3.d/S50apache /etc/rc3.d/.NOS50apache and reboot
WARNING: ncakmod is set to start in runlevel 2
INFO: mv /etc/rc2.d/S42ncakmod /etc/rc2.d/.NOS42ncakmod and reboot
WARNING: ncalogd is set to start in runlevel 2
INFO: mv /etc/rc2.d/S94ncalogd /etc/rc2.d/.NOS94ncalogd and reboot
=====================================================
[ Checking SNMP Service ]
=====================================================
OK: initsma not set to start in runlevel 3
=====================================================
[ Checking INETD ]
=====================================================
WARNING: Service "svc:/network/inetd:default" is [online]
=====================================================
=====================================================
[ Checking System Accounts ]
=====================================================
WARNING: Account bin's password is state [NL]
INFO: Consider locking with "passwd -l bin"
WARNING: Account bin's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null bin
WARNING: Account nuucp's password is state [NL]
INFO: Consider locking with "passwd -l nuucp"
WARNING: Account nuucp's shell is [/usr/lib/uucp/uucico]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null nuucp
WARNING: Account smmsp's password is state [NL]
INFO: Consider locking with "passwd -l smmsp"
WARNING: Account smmsp's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null smmsp
WARNING: Account listen's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null listen
WARNING: Account gdm's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null gdm
OK: System user webserverd not present
WARNING: Account nobody's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null nobody
WARNING: Account noaccess's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null noaccess
WARNING: Account nobody4's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null nobody4
WARNING: Account sys's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null sys
WARNING: Account adm's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null adm
WARNING: Account lp's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null lp
WARNING: Account uucp's shell is [/sbin/sh]
INFO: Consider changing to /dev/null or /bin/false with:
INFO: passmgmt -m -s /dev/null uucp
=====================================================
[ Checking for Accounts With Empty Passwords ]
=====================================================
OK: No accounts have empty passwords
=====================================================
[ Checking for Legacy "+" Entries in passwd Files ]
=====================================================
OK: No legacy "+" entries found
=====================================================
[ Checking for UID 0 Accounts ]
=====================================================
OK: Only "root" has UID 0
=====================================================
[ Checking UMASK and mesg Settings ]
=====================================================
WARNING: UMASK should be more restrictive in /etc/default/login
INFO: Execute the following commands to implement this:
INFO: cd /etc/default
INFO: sed 's/^[#]\{0,1\}UMASK=.*$/UMASK=077/' login > login.new
INFO: mv login.new login
INFO: pkgchk -f -n -p /etc/default/login
WARNING: umask not set correctly in /etc/profile
WARNING: mesg not set correctly in /etc/profile
WARNING: umask not set correctly in /etc/.login
WARNING: mesg not set correctly in /etc/.login
=====================================================
=====================================================
[ Checking "coreadm" Configuration ]
=====================================================
WARNING: Incorrect global core file pattern
WARNING: Incorrect global core file content
WARNING: Incorrect init core file pattern
WARNING: Incorrect init core file content
WARNING: Per-process core dumps are enabled
WARNING: Global SETUID core dumps are disabled
WARNING: Global core dump logging is disabled
WARNING: One or more issues found whilst parsing _optimum_ coreadm settings
INFO: To configure "recommended" coreadm settings, issue the following commands:
INFO: mkdir -p /var/core
INFO: chown root:root /var/core
INFO: chmod 700 /var/core
INFO: coreadm -g /var/core/core_%n_%f_%u_%g_%t_%p -e log -e global \
INFO: -e global-setid -d process -d proc-setid
=====================================================
[ Checking Stack Protection ]
=====================================================
WARNING: noexec_user_stack not set to 1 in /etc/system
WARNING: noexec_user_stack_log not set to 1 in /etc/system
=====================================================
[ Checking NFS Priviledged Port Restrictions ]
=====================================================
WARNING: nfssrv:nfs_portmon not set to 1 in /etc/system
=====================================================
[ Checking TCP Sequence Numbers ]
=====================================================
WARNING: Not using RFC 1948 for TCP initial sequence number generation
=====================================================
[ Checking Network Parameters ]
=====================================================
WARNING: tcp_conn_req_max_q0 set incorrectly
INFO: run: "ndd -set /dev/tcp tcp_conn_req_max_q0 4096" on startup
WARNING: tcp_conn_req_max_q set incorrectly
INFO: run: "ndd -set /dev/tcp tcp_conn_req_max_q 1024" on startup
WARNING: ip_respond_to_echo_broadcast set incorrectly
INFO: run: "ndd -set /dev/ip ip_respond_to_echo_broadcast 0" on startup
WARNING: arp_cleanup_interval set incorrectly
INFO: run: "ndd -set /dev/arp arp_cleanup_interval 60000" on startup
WARNING: ip_ire_arp_interval set incorrectly
INFO: run: "ndd -set /dev/ip ip_ire_arp_interval 60000" on startup
WARNING: ip_ignore_redirect set incorrectly
INFO: run: "ndd -set /dev/ip ip_ignore_redirect 1" on startup
WARNING: ip6_ignore_redirect set incorrectly
INFO: run: "ndd -set /dev/ip ip6_ignore_redirect 1" on startup
WARNING: ip_strict_dst_multihoming set incorrectly
INFO: run: "ndd -set /dev/ip ip_strict_dst_multihoming 1" on startup
INFO: The next parameters flagged (if any) should only be modified if this
INFO: server will not be performing routing
WARNING: ip6_strict_dst_multihoming set incorrectly
INFO: run: "ndd -set /dev/ip ip6_strict_dst_multihoming 1" on startup
WARNING: ip_send_redirects set incorrectly
INFO: run: "ndd -set /dev/ip ip_send_redirects 0" on startup
WARNING: ip6_send_redirects set incorrectly
INFO: run: "ndd -set /dev/ip ip6_send_redirects 0" on startup
WARNING: IP forwarding is enabled on this server
INFO: To disable, execute the following command:
INFO: /usr/sbin/routeadm -d ipv4-forwarding -d ipv6-forwarding
WARNING: Network Parameters not optimally configured
INFO: Create a script to automatically set the correct parameters at boot time
=====================================================
[ Checking inetd Tracing ]
=====================================================
WARNING: inetd tracing is not enabled
INFO: Consider turning this on with the following command:
INFO: /usr/sbin/inetadm -M tcp_trace=true
INFO: or, for individual services
INFO: /usr/sbin/inetadm -m tcp_trace=true
=====================================================
[ Checking FTP Logging ]
=====================================================
OK: FTP disabled, not installed, or broken
=====================================================
[ Checking Connection Logging ]
=====================================================
INFO: Checking whether we are logging daemon.debug to a connection log
WARNING: Not logging daemon.debug to /var/log/connlog
INFO: It is recommended that you execute the following commands
INFO: to instate a connection log: (use an echo that supports -e)
INFO: printf "daemon.debug\t\t\t/var/log/connlog\n" >> /etc/syslog.conf
INFO: touch /var/log/connlog
INFO: chown root:root /var/log/connlog
INFO: chmod 600 /var/log/connlog
INFO: logadm -w connlog -C 13 -a 'pkill -HUP syslogd' /var/log/connlog
=====================================================
[ Checking syslog AUTH Logging ]
=====================================================
WARNING: Not logging auth.info to /var/log/authlog
INFO: It is recommended that you execute the following commands
INFO: to capture messages sent to the syslog AUTH facility:
INFO: printf "auth.info\t\t\t/var/log/authlog\n" >> /etc/syslog.conf
INFO: touch /var/log/authlog
INFO: chown root:root /var/log/authlog
INFO: chmod 600 /var/log/authlog
INFO: logadm -w authlog -C 13 -a 'pkill -HUP syslogd' /var/log/authlog
=====================================================
[ Checking logging of failed login attempts ]
=====================================================
WARNING: SYSLOG_FAILED_LOGINS not set to 0 in /etc/default/login
INFO: It is recommended that you execute the following commands
INFO: to log all failed logins to /var/adm/loginlog:
INFO: touch /var/adm/loginlog
INFO: chown root:sys /var/adm/loginlog
INFO: chmod 600 /var/adm/loginlog
INFO: cd /etc/default
INFO: sed 's/^[#]\{0,1\}SYSLOG_FAILED_LOGINS=.*$/SYSLOG_FAILED_LOGINS=0/' login > login.new
INFO: mv login.new login
INFO: pkgchk -f -n -p /etc/default/login
INFO: logadm -w loginlog -C 13 /var/adm/loginlog
=====================================================
[ Checking cron logging ]
=====================================================
OK: cron logging is enabled
=====================================================
[ Checking System Accounting ]
=====================================================
WARNING: Service svc:/system/sar:default is [disabled]
WARNING: One or more System Accounting entries in crontab for user "sys"
WARNING: not present or incorrect. Ensure the following entries are present:
INFO: 0,20,40 * * * * /usr/lib/sa/sa1
INFO: 45 23 * * * /usr/lib/sa/sa2 -s 0:00 -e 23:59 -i 1200 -A
=====================================================
[ Checking System Log File Permissions ]
=====================================================
INFO: Will now check /var/log/syslog, /var/log/authlog, /var/adm/utmpx, /var/adm/wtmpx
INFO: with pkgchk. Review output (if any) for inconsistencies.
OK: No errors found
=====================================================
=====================================================
[ Checking for "login:" Prompts on Serial Ports ]
=====================================================
WARNING: login: prompt enabled on serial port ttya
INFO: To disable, execute the following command:
INFO: pmadm -d -p zsmon -s ttya
WARNING: login: prompt enabled on serial port ttyb
INFO: To disable, execute the following command:
INFO: pmadm -d -p zsmon -s ttyb
=====================================================
[ Checking "nobody" Access for Secure RPC ]
=====================================================
WARNING: "nobody" access to Secure RPC not explicitly disabled in /etc/default/keyserv
INFO: Execute the following commands to disable:
INFO: cd /etc/default
INFO: sed 's/^[#]\{0,1\}ENABLE_NOBODY_KEYS=.*$/ENABLE_NOBODY_KEYS=NO/' keyserv > keyserv.new
INFO: mv keyserv.new keyserv
INFO: pkgchk -f -n -p /etc/default/keyserv
=====================================================
[ Checking SSH Daemon Configuration ]
=====================================================
INFO: Where warnings are found whilst parsing /etc/ssh/sshd_config, either
INFO: uncomment and/or fix the entries contained therein
OK: "Protocol" set to "2" in /etc/ssh/sshd_config
OK: "X11Forwarding" set to "yes" in /etc/ssh/sshd_config
WARNING: "MaxAuthTries" not set to "5" in /etc/ssh/sshd_config
WARNING: "MaxAuthTriesLog" not set to "0" in /etc/ssh/sshd_config
OK: "RhostsAuthentication" set to "no" in /etc/ssh/sshd_config
OK: "RhostsRSAAuthentication" set to "no" in /etc/ssh/sshd_config
OK: "PermitRootLogin" set to "no" in /etc/ssh/sshd_config
OK: "PermitEmptyPasswords" set to "no" in /etc/ssh/sshd_config
WARNING: "Banner" not set to "/etc/issue" in /etc/ssh/sshd_config
=====================================================
[ Checking for .rhosts Support in /etc/pam.conf ]
=====================================================
WARNING: .rhosts support exists in /etc/pam.conf
INFO: It is recommended that you remove .rhosts support in /etc/pam.conf
INFO: Execute the following commands to do this:
INFO: cd /etc
INFO: grep -v "pam_rhosts_auth\.so\.1" pam.conf > pam.conf.new
INFO: mv pam.conf.new pam.conf
INFO: pkgchk -f -n -p /etc/pam.conf
=====================================================
[ Checking /etc/ftpd/ftpusers ]
=====================================================
OK: Service "svc:/network/ftp:default" is disabled
=====================================================
[ Checking That sendmail Only Listens Locally ]
=====================================================
INFO: Checking is sendmail is disabled from listening on external interfaces
INFO: Obviously if this is a mail server, ignore these test results
WARNING: sendmail not configured to listen locally only on port 25
INFO: To configure, execute the following commands:
INFO: sed 's/^\(O DaemonPortOptions.*inet\)$/\1, Addr=127.0.0.1/' /etc/mail/sendmail.cf > /etc/mail/sendmail.cf.new
INFO: mv /etc/mail/sendmail.cf.new /etc/mail/sendmail.cf
INFO: svcadm refresh svc:/network/smtp:sendmail
WARNING: sendmail configured to listen on IPv6 addresses
INFO: Unless you use IPv6 at your site, this isn't required
INFO: To disable sendmail on IPv6 addresses, enter the following commands:
INFO: sed 's/^\(O DaemonPortOptions.*inet6.*\)$/#\1/' /etc/mail/sendmail.cf > /etc/mail/sendmail.cf.new
INFO: mv /etc/mail/sendmail.cf.new /etc/mail/sendmail.cf
INFO: svcadm refresh svc:/network/smtp:sendmail
=====================================================
[ Checking That syslogd Will Not Accept Remote Messages ]
=====================================================
WARNING: syslogd not configured to reject remote messages
INFO: It is recommended that you do not allow syslogd to listen for
INFO: messages from other systems, unless this server is a log server
INFO: To disable, execute the following commands:
INFO: cd /etc/default
INFO: sed 's/^[#]\{0,1\}LOG_FROM_REMOTE=.*$/LOG_FROM_REMOTE=NO/' syslogd > syslogd.new
INFO: mv syslogd.new syslogd
INFO: svcadm refresh svc:/system/system-log:default
=====================================================
[ Checking That TCP Wrappers is Enabled ]
=====================================================
WARNING: /etc/hosts.allow does not exist
WARNING: /etc/hosts.deny does not exist
WARNING: Global TCP Wrappers configuration not enabled
INFO: To enable, execute the following command:
INFO: inetadm -M tcp_wrappers=TRUE
=====================================================
[ Checking crontabs ]
=====================================================
INFO: The crontab [/var/spool/cron/crontabs/adm] is empty - consider removing it
INFO: with "crontab -r adm"
WARNING: /var/spool/cron/crontabs/adm is not mode 400. Execute the following command to fix it:
INFO: chmod 400 /var/spool/cron/crontabs/adm
WARNING: /var/spool/cron/crontabs/dim is not owned by group sys. Execute the following command to fix it:
INFO: chgrp sys /var/spool/cron/crontabs/dim
WARNING: /var/spool/cron/crontabs/dim is not mode 400. Execute the following command to fix it:
INFO: chmod 400 /var/spool/cron/crontabs/dim
WARNING: /var/spool/cron/crontabs/lp is not owned by group sys. Execute the following command to fix it:
INFO: chgrp sys /var/spool/cron/crontabs/lp
WARNING: /var/spool/cron/crontabs/root is not mode 400. Execute the following command to fix it:
INFO: chmod 400 /var/spool/cron/crontabs/root
INFO: The crontab [/var/spool/cron/crontabs/sys] is empty - consider removing it
INFO: with "crontab -r sys"
WARNING: /var/spool/cron/crontabs/sys is not mode 400. Execute the following command to fix it:
INFO: chmod 400 /var/spool/cron/crontabs/sys
INFO: The crontab [/var/spool/cron/crontabs/uucp] is empty - consider removing it
INFO: with "crontab -r uucp"
=====================================================
[ Checking cron Facility Access ]
=====================================================
WARNING: /etc/cron.d/cron.allow does not exist
WARNING: /etc/cron.d/at.allow does not exist
WARNING: No need for /etc/cron.d/cron.deny ( if /etc/cron.d/cron.allow exists )
WARNING: No need for /etc/cron.d/at.deny ( if /etc/cron.d/at.allow exists )
=====================================================
[ Checking That root Can Only Log in on /dev/console ]
=====================================================
OK: CONSOLE variable correctly configured in /etc/default/login
=====================================================
[ Checking Account Lockout Policy ]
=====================================================
WARNING: Bad login attempt retry limit not set to 5 (or less) in /etc/default/login
INFO: To force reconnection after 5 bad login attempts, execute the following commands:
INFO: cd /etc/default
INFO: sed 's/^[#]\{0,1\}RETRIES=.*$/RETRIES=5/' login > login.new
INFO: mv login.new login
INFO: pkgchk -f -n -p /etc/default/login
WARNING: Accounts not set to lock after RETRIES limit reached
INFO: To lock accounts after RETRIES limit reached, execute the following commands:
INFO: cd /etc/security
INFO: sed 's/^[#]\{0,1\}LOCK_AFTER_RETRIES=.*$/LOCK_AFTER_RETRIES=YES/' policy.conf > policy.conf.new
INFO: mv policy.conf.new policy.conf
INFO: pkgchk -f -n -p /etc/security/policy.conf
INFO: You can then disable lockout for particular users with:
INFO: usermod -K lock_after_retries=no username
=====================================================
=====================================================
[ Checking Daemon umask ]
=====================================================
OK: CMASK set correctly in /etc/default/init
=====================================================
[ Checking rmmount.conf ]
=====================================================
OK: Line: "mount * hsfs udfs ufs -o nosuid" in /etc/rmmount.conf has nosuid option set
=====================================================
[ Checking passwd Files ]
=====================================================
INFO: /etc/passwd, /etc/group and /etc/shadow will now be checked with pkgchk.
INFO: Review the output (if any) and take corrective action as required
ERROR: /etc/passwd
modtime <08/25/08 05:44:51 PM> expected <07/06/10 02:40:00 PM> actual
file size <672> expected <767> actual
file cksum <56039> expected <64080> actual
ERROR: /etc/group
modtime <08/25/08 05:44:50 PM> expected <07/06/10 02:39:57 PM> actual
file size <289> expected <299> actual
file cksum <23837> expected <24480> actual
ERROR: /etc/shadow
modtime <08/25/08 05:44:51 PM> expected <07/06/10 02:40:00 PM> actual
file size <338> expected <402> actual
file cksum <23267> expected <28033> actual
=====================================================
[ Checking World Writable Directories For Sticky Bit ]
=====================================================
INFO: Preparing a list of directories that are world-writable and DO NOT
INFO: have their sticky bit set - review and correct if necessary
drwxrwxrwx 2 root nobody 182 Jul 12 13:30 /tmp/.removable
=====================================================
[ Checking for World Writable Files ]
=====================================================
INFO: Preparing a list of files that are world-writable review and correct if necessary
-rw-rw-rw- 1 root bin 0 Aug 25 2008 /var/adm/spellhist
-rw-rw-rw- 1 root root 8 Dec 21 2001 /var/dt/dtpower/_current_scheme
-rw--w--w- 1 bin bin 0 Jan 22 2005 /usr/oasys/tmp/TERRLOG
-rw-rw-rw- 1 root root 0 Jul 12 13:30 /proc/1/fd/254
-rw-rw-rw- 1 root root 0 Jul 12 13:30 /proc/1/fd/255
-rw-rw-rw- 1 root root 0 Jul 12 13:30 /proc/392/fd/11
-rw-rw-rw- 1 root root 0 Jul 12 13:30 /proc/504/fd/7
-rw-rw-rw- 1 root root 0 Jul 12 13:30 /system/contract/process/template
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/1/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/1/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/4/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/4/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/5/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/5/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/20/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/20/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/21/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/21/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/24/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/24/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/27/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/27/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/28/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/28/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/36/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/36/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/42/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/42/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/43/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/43/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/44/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/44/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/48/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/48/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/49/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/49/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/50/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/50/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/51/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/51/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/53/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/53/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/55/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/55/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/56/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/56/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/58/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/58/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/65/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/65/status
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/74/ctl
--w--w--w- 1 root root 0 Jul 12 13:30 /system/contract/process/74/status
--w--w--w- 1 root root 0 Jul 12 13:46 /system/contract/process/86/ctl
--w--w--w- 1 root root 0 Jul 12 13:46 /system/contract/process/86/status
--w--w--w- 1 root root 0 Jul 12 17:06 /system/contract/process/91/ctl
--w--w--w- 1 root root 0 Jul 12 17:06 /system/contract/process/91/status
--w--w--w- 1 root root 0 Jul 12 18:37 /system/contract/process/95/ctl
--w--w--w- 1 root root 0 Jul 12 18:37 /system/contract/process/95/status
--w--w--w- 1 root root 0 Jul 13 03:30 /system/contract/process/98/ctl
--w--w--w- 1 root root 0 Jul 13 03:30 /system/contract/process/98/status
=====================================================
[ Checking for SUID/SGID System Executables ]
=====================================================
INFO: Preparing a list of files that are SUID/SGID and executable
-r-xr-sr-x 1 root sys 14716 Jan 8 2007 /usr/platform/i86pc/sbin/eeprom
-r-sr-xr-x 1 root sys 23968 Jan 23 2005 /usr/bin/amd64/newtask
-r-sr-xr-x 2 root bin 15584 Jan 23 2005 /usr/bin/amd64/uptime
-r-sr-xr-x 2 root bin 15584 Jan 23 2005 /usr/bin/amd64/w
-r-sr-xr-x 1 root sys 14372 Jan 23 2005 /usr/bin/i86/newtask
-r-sr-xr-x 2 root bin 14200 Jan 23 2005 /usr/bin/i86/uptime
-r-sr-xr-x 2 root bin 14200 Jan 23 2005 /usr/bin/i86/w
-rwsr-xr-x 1 root sys 36560 Jul 3 2008 /usr/bin/at
-rwsr-xr-x 1 root sys 14652 Jul 3 2008 /usr/bin/atq
-rwsr-xr-x 1 root sys 14592 Jul 3 2008 /usr/bin/atrm
-r-sr-xr-x 1 root bin 15708 Jul 3 2008 /usr/bin/crontab
-r-sr-xr-x 1 root bin 14468 Jan 23 2005 /usr/bin/eject
-r-sr-xr-x 1 root bin 27116 Jan 23 2005 /usr/bin/fdformat
-r-sr-xr-x 1 root bin 30540 Jan 23 2005 /usr/bin/login
-r-x--s--x 1 root mail 58872 Jan 25 2008 /usr/bin/mail
-r-x--s--x 1 root mail 109192 Oct 11 2007 /usr/bin/mailx
-rwsr-xr-x 1 root sys 10324 Jan 23 2005 /usr/bin/newgrp
-r-sr-sr-x 1 root sys 22628 Aug 14 2007 /usr/bin/passwd
-r-sr-xr-x 1 root bin 14300 Jan 23 2005 /usr/bin/pfexec
-r-sr-xr-x 1 root sys 25144 May 25 2005 /usr/bin/su
-r-s--x--x 1 uucp bin 51408 Jan 5 2007 /usr/bin/tip
-r-xr-sr-x 1 root tty 14208 Jan 23 2005 /usr/bin/write
-r-sr-xr-x 1 root bin 40948 Mar 19 2008 /usr/bin/rcp
-r-sr-xr-x 1 root bin 67616 Mar 19 2008 /usr/bin/rdist
-r-sr-xr-x 1 root bin 31672 Mar 19 2008 /usr/bin/rlogin
-r-sr-xr-x 1 root bin 27044 Mar 19 2008 /usr/bin/rsh
-rwsr-xr-x 1 svctag daemon 102752 May 28 2008 /usr/bin/stclient
-rwsr-xr-x 1 root other 165192 Nov 8 2006 /usr/bin/tsoljdslabel
-r-s--x--x 1 root uucp 60516 Feb 20 2008 /usr/bin/ct
-r-s--x--x 1 uucp uucp 75800 Feb 20 2008 /usr/bin/cu
-r-s--x--x 1 uucp uucp 60292 Jan 23 2005 /usr/bin/uucp
-r-s--x--x 1 uucp uucp 23868 Jan 23 2005 /usr/bin/uuglist
-r-s--x--x 1 uucp uucp 21036 Jan 23 2005 /usr/bin/uuname
-r-s--x--x 1 uucp uucp 55404 Jan 23 2005 /usr/bin/uustat
-r-s--x--x 1 uucp uucp 64488 Jan 23 2005 /usr/bin/uux
-r-sr-xr-x 1 root bin 52368 Jan 8 2007 /usr/bin/rmformat
-r-sr-xr-x 1 root bin 14280 Jan 23 2005 /usr/bin/volrmmount
-rwsr-xr-x 1 root bin 55660 May 22 2008 /usr/bin/cdrw
-r-s--x--x 1 root lp 10060 Mar 19 2008 /usr/bin/lpset
-r-sr-xr-x 1 root sys 43872 Aug 14 2007 /usr/bin/chkey
-r-sr-xr-x 1 root bin 195212 Aug 14 2007 /usr/bin/pppd
-r-sr-xr-x 1 root bin 5844 Jan 25 2008 /usr/bin/mailq
-r-sr-xr-x 1 root bin 14496 Jan 23 2005 /usr/lib/fs/ufs/quota
-r-sr-xr-x 1 root bin 80644 Oct 3 2008 /usr/lib/fs/ufs/ufsdump
-r-sr-xr-x 1 root bin 86716 Oct 3 2008 /usr/lib/fs/ufs/ufsrestore
-r-s--x--x 1 root bin 5776 Jan 8 2007 /usr/lib/pt_chmod
-r-sr-xr-x 1 root bin 9972 Jan 23 2005 /usr/lib/utmp_update
-r-s--x--x 1 root sys 51748 Jul 13 2008 /usr/lib/cacao/lib/tools/cacaocsc
-r-s--x--x 1 root bin 19008 Mar 19 2008 /usr/lib/lp/bin/netpr
-rwsr-xr-x 1 root adm 5772 Jan 23 2005 /usr/lib/acct/accton
-r-sr-xr-x 1 root sys 20548 Jun 14 2007 /usr/lib/webconsole/pamverifier
-r-s--x--x 1 uucp uucp 6032 Jan 23 2005 /usr/lib/uucp/remote.unknown
-r-s--x--x 1 uucp uucp 142840 Feb 20 2008 /usr/lib/uucp/uucico
-r-s--x--x 1 uucp uucp 33184 Jan 23 2005 /usr/lib/uucp/uusched
-r-s--x--x 1 uucp uucp 78448 Jan 23 2005 /usr/lib/uucp/uuxqt
-r-s--x--x 1 root bin 45220 Mar 19 2008 /usr/lib/print/lpd-port
-r-xr-sr-x 1 root smmsp 837860 Jan 25 2008 /usr/lib/sendmail
-r-sr-xr-x 1 root bin 138416 Oct 3 2008 /usr/lib/ssh/ssh-keysign
-rws--x--x 1 root other 10684 Dec 16 2004 /usr/lib/gnome-suspend
-rwxr-sr-x 1 root root 1612028 Jul 23 2008 /usr/openwin/bin/Xprt
-rwsr-xr-x 1 root bin 1408716 Jul 23 2008 /usr/openwin/bin/Xsun
-rwxr-sr-x 1 root root 305652 Jul 23 2008 /usr/openwin/bin/lbxproxy
-rwsr-xr-x 1 root bin 73220 Jan 23 2005 /usr/openwin/bin/xlock
-r-sr-xr-x 1 root bin 37996 Mar 28 2007 /usr/openwin/bin/sys-suspend
-rwsr-xr-x 1 root bin 327232 Jun 11 2008 /usr/openwin/bin/xscreensaver
-r-xr-sr-x 1 root sys 40104 Jan 8 2007 /usr/sbin/amd64/prtconf
-r-xr-sr-x 1 root sys 15496 Oct 3 2008 /usr/sbin/amd64/swap
-r-xr-sr-x 1 root sys 24032 Jan 23 2005 /usr/sbin/amd64/sysdef
-r-sr-xr-x 1 root bin 15568 Jan 23 2005 /usr/sbin/amd64/whodo
-r-xr-sr-x 1 root sys 30352 Jan 8 2007 /usr/sbin/i86/prtconf
-r-xr-sr-x 1 root sys 14052 Oct 3 2008 /usr/sbin/i86/swap
-r-xr-sr-x 1 root sys 18608 Jan 23 2005 /usr/sbin/i86/sysdef
-r-sr-xr-x 1 root bin 14216 Jan 23 2005 /usr/sbin/i86/whodo
-r-sr-xr-x 3 root bin 31516 Mar 19 2008 /usr/sbin/allocate
-rwsr-xr-x 1 root sys 24276 Jan 23 2005 /usr/sbin/sacadm
-r-sr-xr-x 1 root bin 35752 Jun 30 2006 /usr/sbin/traceroute
-r-xr-sr-x 1 root tty 10592 Jan 23 2005 /usr/sbin/wall
-r-sr-xr-x 3 root bin 31516 Mar 19 2008 /usr/sbin/deallocate
-r-sr-xr-x 3 root bin 31516 Mar 19 2008 /usr/sbin/list_devices
-r-sr-xr-x 1 root bin 45016 Apr 26 2005 /usr/sbin/ping
-r-sr-xr-x 1 root bin 21272 Jun 12 2008 /usr/sbin/pmconfig
-r-sr-xr-x 1 root bin 216440 Aug 8 2007 /usr/sbin/smpatch
-rwsr-xr-x 1 root sys 36580 Jul 3 2008 /usr/xpg4/bin/at
-r-sr-xr-x 1 root bin 15724 Jul 3 2008 /usr/xpg4/bin/crontab
-r-sr-sr-x 1 root sys 23124 Sep 29 2006 /usr/dt/bin/dtaction
-r-sr-xr-x 1 root bin 33116 Jan 23 2005 /usr/dt/bin/dtappgather
-r-sr-sr-x 1 root daemon 267768 Jan 23 2005 /usr/dt/bin/sdtcm_convert
-r-sr-xr-x 1 root bin 590140 Sep 29 2006 /usr/dt/bin/dtfile
-r-xr-sr-x 1 root mail 1376940 Sep 14 2006 /usr/dt/bin/dtmail
-r-xr-sr-x 1 root mail 409664 Jan 23 2005 /usr/dt/bin/dtmailpr
-r-sr-xr-x 1 root bin 327012 Jan 23 2005 /usr/dt/bin/dtprintinfo
-r-sr-xr-x 1 root bin 154584 Nov 8 2007 /usr/dt/bin/dtsession
-r-sr-xr-x 1 root bin 32068 Jul 18 2008 /usr/dt/bin/tsoldtlabel
-r-sr-xr-x 1 root bin 59696 Jul 18 2008 /usr/dt/bin/tsolxagent
-r-sr-xr-x 1 root bin 2374712 Jul 23 2008 /usr/X11/bin/amd64/Xorg
-r-sr-xr-x 1 root bin 2120536 Jul 23 2008 /usr/X11/bin/Xorg
-r-xr-sr-x 1 root root 4005000 Jul 23 2008 /usr/X11/bin/Xvnc
-r-sr-xr-x 1 root bin 15724 Jul 3 2008 /usr/xpg6/bin/crontab
-r-sr-sr-x 1 bin bin 10080 Jan 23 2005 /usr/vmsys/bin/chkperm
-rwxr-sr-x 1 root sys 214240 Jul 11 2008 /usr/local/bin/amd64/lsof
-rwxr-sr-x 1 root sys 183724 Jul 11 2008 /usr/local/bin/i386/lsof
-r-xr-sr-x 1 root sys 5816 Jul 11 2008 /usr/local/bin/lsof
-r-sr-xr-x 1 root lp 203 Jan 10 2005 /etc/lp/alerts/printer
-r-xr-sr-x 1 root smmsp 837860 Jan 25 2008 /proc/685/object/a.out
-r-xr-sr-x 1 root smmsp 837860 Jan 25 2008 /proc/684/object/a.out
=====================================================
[ Checking for Unowned Files and Directories ]
=====================================================
INFO: Checking for "unowned" files and directories
=====================================================
[ Checking for Extended Attributes ]
=====================================================
INFO: Checking for files and directories with exteneded attributes
=====================================================
SCAN FINISHED: Tue Jul 13 12:43:17 CEST 2010
=====================================================

Routing Protokollok

Többféle routing protokoll létezik némelyik nagyon okos (mint mondjuk az OSPF) némelyik kevésbé mint mondjuk a RIP 1). Ezek a routing protokollok a routereink közötti belső metrika és network topológia feltérképezését végzik automatikusan. A belső szó azért fontos mert az internet végpontra való csatlakozáshoz más routing protokollok kellenek mint mondjuk a BGP! Az automatikusan szó pedig azért mert lehet manuális, „kézi” routokat is beállítani, ha úgy tartja kedvünk. Ha pl van egy irodánk Budapesten egy meg Tatabányán és a 2 irodát bérelt volani WAN kapcsolat köti össze akkor a 2 routeren be lehet állítani egy automatikus routing protokollt mondjuk egy jó kis OSPF et, és úgymond ezzel kötjük össze a 2 irodánk hálózatát, ezzel mondjuk meg mi merre van, ezzel irányítjuk 8irányítja a router automatikusan) melyik forgalom merre menjen.

Nézzük meg az OSPF beállítását egy példán keresztül:

2 iroda, 2 router, 1-1 switch, 1-1 PC, és a routereinket bérelt vonalon kötöttük össze jelen esetben soros kapcsolattal mert a szolgáltató ilyen véget adott...

Az 2 router közötti kapcsolat legyen 192.168.10.0/24
A Budapesti irodában legyen 192.168.1.0/24 es hálózat
A tatabányai irodában pedíg legyen 192.168.2.0/24 es hálózat

Szépen felkonfiguráljuk az interfészeinket értelemszerűen. Miután ez megvan, a PC-inknek is adunk 1-1 IP címet és mivel ezek ugye külön alhálózatba lesznek egyenlőre nem fogják tudni elérni egymást... Viszont tudják a saját alapértelmezett GW-üket ami ugye a Router belső lába. Innen a routernek kellene továbblőni a forgalmat, node merre? Ezt deríti fel a routing protokoll (vagy adott esetben ezt adjuk meg kézi routokkal).

Lássuk akkor az OSPF beállítását:

Az első parancsot (config)# konfig módban kell kiadni „router ospf azonosító”

Itt egyből át is dob minket a protokoll konfigurációs módjába. Az „1”-es szám egy azonosító amivel később ugyanerre a beállított protokollra hivatkozhatunk. Most meg kell adni az összes olyan hálózatot amit a router ismer mert ő ezeket a hálózatokat fogja hirdetni. Mik is ezek a hálózatok? Hát amik direktbe kapcsolódva vannak hozzá. Itt mondjuk van egy alhálózat a router belső lábán és egy alhálózat a serial interfészén. A példába nem sokat számolgattam hova mekkora hálózatot tegyek ezért mindenhová /24 es került. A parancs így néz ki:

(Az 1.0 –ás hálózat a router belső lábán lévő hálózat a 10.0-ás pedig a 2 iroda közötti kapcsolat hálózata) Fontos hogy fordított maszkkal kell az OSPF-nél dolgozni tehát 255.255.255.0 helyett nekünk 0.0.0.255 öt kell írni mert miért ne? Ez a routing protokolloknál változó érdemes megnézni a parancsait a neten mielőtt belefogunk egy ilyenbe. A másik routeren tök ugyanezt kell beállítani csak értelemszerűen az ottani hálózatokkal. A 192.168.10.0 az ugye közös és mondjuk oda meg tegyünk 192.168.2.0 –át a belső lábára.
Ezek után miután mind2 router tudja hogy mely hálózatokat ismer ő és miket kell hirdetnie kifelé, lássuk hogy történt e valami. Kérdezzük le a route táblát a „sh ip route paranccsal”

A felső rész egy jelmagyarázat, az első pedig a routing táblánk. Láthatjuk hogy a Router „C” betűvel jelzi azokat a hálózatokat amik direktbe kapcsolódva vannak hozzá, de mi az a sor az „O” betűvel? Hát az már az OSPF. A mi jó kis OSPF ünk fogta magát és felderítette a másik router által küldött cuccot, így most már ez a router tudja hogy a másik routernek az egyik lábán van egy alhálózat amit 192.168.2.0-ának hívnak... na amit itt most belőttünk kicsiben, az működik nagyban is. Ezzel gyakorlatilag van egy működő hálózatunk.

Statikus (kézi) route-ok

Megnéztük korábban ugye az automatikus routing protokollokat (RIP, EIGRP, OSPF), amik szépen felderítik a hálózatot és teljesen automatikusan routolják a forgalmat a felderített információ alapján, és ha pontosan nem is tudják hova kell küldeni a csomagot, de mindenképp egy jó irányba vagy olyan eszközhöz küldik ami már tudja hogy merre van a cél. Az automatikus routing protokollok mellett használhatunk viszont kézzel beállított statikus routokat is. Ezeket használhatjuk akár együtt is, de kis hálózat esetén akár használhatunk csak statikus routokat is.

Nézzük meg ezt a nagyon egyszerű hálózatot és próbáljuk meg kézzel beállítani azt ami nem megy. Az egyszerűség kedvéért mindenhol /24 es alhálózatok vannak. Nyilván a célunk hogy PC0 és PC1 elérjék egymást (nyilván csak a példában van 2 gép de a cél hogy a 2 hálózat átjárható legyen). Nézzük szét a PC0-ról meddig látunk el? Az alapértelmezett gw-t biztos látjuk hiszen azok egy alhálózaton vannak. Kezdjünk pingelni egy kicsit tovább. Látjuk hogy még a 192.168.5.1 et is elérjük, tehát a router külső lábát (fogalmazzuk így hiszen PC0 szemszögéből nézzük a dolgokat) viszont a 192.168.5.2-t már nem. Miért is van ez így? Hiszen ha már elérjük a routerünk külső lábát, és a routerünk ismeri a 192.168.5.2-t hiszen közvetlen kapcsolatban van vele akkor miért nem érjük el? Hát azért, mert senki nem mondta meg a routernek hogy az abba az irányba menő forgalommal mit csináljon hiszen nincsenek route-ok. Nyilván magából a routerből tudjuk pingelni a következő Routert de a PC-ről nem. Természetesen ennélfogva a PC0-ról nem fogjuk elérni a PC1-et. Próbáljuk meg korrigálni a dolgot.

A parancs struktúrája nagyon egyszerű, egyszerűen azt mondjuk neki hogy az „Ebbe” az irányba menő forgalmat küld el „erre”. A parancs az „ip route”.

Router(config)#ip route 192.168.2.0 255.255.255.0 192.168.5.2

Vagy

Router(config)#ip route 192.168.2.0 255.255.255.0 f0/0

A kettő teljesen ugyan az, az elsőnél a másik router lábát adtuk meg neki (annak a routernek a lábát amerre szeretnénk hogy menjen a forgalom) a másodiknál pedig a router saját interfészét (azt az interfészt amelyiken szeretnénk hogy azon menjen ki a forgalom). Hogy melyiket jobb használni, erre nincs konkrét válaszom, attól függ hogy a jövőben az IP-ket vagy az interfészeinket szeretnénk lecserélni. Lássuk most működik e a dolog és látja e egymást a 2 PC. Sajnos nem. De miért nem? Hát most már route is van elrontottunk valamit? Nem, de ha belegondolunk megírtuk az útvonalat az egyik irányba, de a csomagunknak vissza is kell találnia! A problémát mind2 oldalról kezelni kell, menjünk be a másik routerbe is, vagyis a Router1 be és írjuk meg az útvonalat visszafele is:

Router(config)#ip route 192.168.1.0 255.255.255.0 192.168.5.1

Mit is csináltunk most? Hát megmondtuk a Router1-nek, hogy ha valaki csomagot küld rajtam keresztül a 192.168.1.0/24-es alhálózatba akkor azt el kell irányítanom a 192.168.5.1 felé vagyis a másik router irányába. Aztán hogy onnan hova megy az már nekem nem számít, a lényeg hogy én odaküldök mindent ami arra akar menni.

Tekintsünk vissza egy pillanatra a hálózati topológiánkra és képzeljük el hogy a Router1 nek van egy Internet végpontja is, amit bizony a felhasználóink előszeretettel használni szeretnének. Hogy mondjuk meg a routerünknek hogy mit küldjön erre és mit küldjön arra és hogy egyáltalán mi felé küldje azt amit küld? Vagy gondoljunk egy olyan szituációra hogy Router1 nek van 8 lába és mindegyiken más alhálózat van. Miért ne lehetne? Ezek szerint Router0-ban mindegy egyes alhálózatra külön route-ot kellene írjunk? Szerencsére nem, hiszen olyat is tudunk mondani a routerünknek, hasonlóképpen mint egy PC-nek, hogy azt amit nem tudsz merre menjen azt küld el „erre” vagyis egy bizonyos irányba. Ezzel gyakorlatilag meg is oldottuk a problémát! Vannak konkrét hálózataink, ezekhez konkrétan megírt routok, ha erre akarsz menni akkor ezen az interfészen menj ki, ha arra akkor meg azon, Viszont ha nem tudod merre menj, akkor tessék itt egy úgymond default route ami megmondja hogy merre küld azt amiről fogalmad sincs merre küld.

Router1(config)#ip route 0.0.0.0 0.0.0.0 „és ide a router saját interfészét adjuk meg pl f1/0”

Ezzel közöltük mondjuk a Router1 el hogy ha a konkrétan definiált route-ok megnézése után sem tudod merre irányítsd a forgalmat akkor küld ki a fasthethernet1/0-ás interfészeden. Statikus routoknál jól meg kell gondolni a mit és hová kell tegyünk, itt mondanék is egy példát, jelen esetben a PC1 gépről boldogan internetezhetünk, viszont a PC0-ról nem igazán, hiszen a Router0-ának csak azt mondtuk meg hol a 192.168.2.0 –ás hálózat, ha PC0-ról az internet felé kéne csomagot küldeni a dolog már a Router0-nál elbukna. Természetesen oda is beállíthatjuk hogy menjen minden forgalom a Router1 felé és a problémát át is hidaltuk, de ez egy szemléletes példa a statikus route-ok használatára.

Még két dolgot szeretnék ide leírni, az egyik hogy akár 1 konkrét host felé is megadhatunk route-ot, ez esetben használjunk 255.255.255.255–ös maszkot

Router0(config)#ip route 192.168.2.100 255.255.255.255 192.168.5.2

Illetve a másik dolog, a meglévő route-jaink lekérdezése a „sh ip route” paranccsal. A statikus route-jainkat „S” betűvel fogja jelezni a router.

Ahol nem adtunk meg úgynevezett default route-ot ott azt fogja írni hogy gateway of last resort is not set, de természetesen ez nem hiba és nem kötelező megadni.

ACL ek (Access Listák)

Képzeljük el hogy van egy már beállított hálózati topológiánk, ahogy minden működik és minden elérhető mindenhonnan. Az ACL ek gyakorlatilag szabályok amik megmondják hogy a már beállított hálózaton (lépjünk túl egy kicsit a routokon és téletezzük vel, hogy itt most valóban minden elérhető mindenhonnan) mi az a forgalom ami engedélyezett és mi az ami nem! Függetlenül attól hogy ismerem az utat, átengedhetem e vagy sem! Gondoljunk bele abba hogy ha mindenki elér mindent ez bizonyos szempontból jó, már már álomszerű lenne ha ezt meg is tehetnénk, viszont a gyakorlatban mi legalább annyit tiltogatunk mint engedélyezünk. Nem feltétlenül jó dolog az ha mindenki elér mindent. Na pontosan erre használhatók ezek a szabályok. Csináljunk pl. egy belső webszervert a Budapesti irodánknak ahova a budapestiek a szupertitkos adataikat publikálják. Mivel ez tényleg csak a Budapesti irodára vonatkozik, hát szeretnénk mi hogy Tatabányáról vagy bárhonnan máshonnan ezek az adatok elérhetők legyenek? Kit érdekel – mondhatnánk mi - természetesen a Budapestieket hiszen ők féltik az adataikat. Mit tehetünk? Fogjuk magunkat és létrehozunk egy olyan szabályt a routeren (hogy melyiken az mindíg attól függ hol a praktikusabb) amivel megtiltjuk hogy a webszerver bárhonnan kívülről elérhető legyen. Egyszerűen nem engedjük át a forgalmat a routeren, kész passz. Még azt is eldönthetjük hogy csak a http forgalmat tiltjuk le vagy teljesen minden IP apaló forgalmat afelé a szerver felé. De nézzük ennek az ellenkezőjét. Mert akár azt is megtehetjük hogy sehová semmilyen forgalmat nem engedünk ki, kivéve afelé az egy webszerver felé a http forgalmat. A lehetőségeink korlátlanok a tekintetben hogy mit engedünk és mit tiltunk meg.

Nem akarok most már túl sokat írni erről, lényeg hogy mielőtt ACL-eket konfigurálnánk gondosan tervezzük meg az egészet! Mindenképpen!!! Ha csak úgy ukk mukk fukk nekiállunk na az biztos nem fog működni. A tervezés azért is fontos, mert ACL-eket utólag módosítani külön tortúra. Ennyi magyarázat épp elég most már nézzük meg inkább egy példán keresztül.

Hogy maradjunk a webes példánál, alul 1-1 külön alhálózatba bepakoltunk 1-1 webszervert és majd a 2 fölső gépről próbáljuk meg engedélyezni illetve tiltani a 2 szerver webes elérését. Természetesen a webes példa alapján elkészíthetitek a saját ACL jeiteket is az igényeknek megfelelően, én most azért maradok ennél a példánál mert ezt nagyon jól lehet Packet Tracerbe szimulálni (a kliensen böngészőt lehet nyitni, a szerveren meg van HTML weboldal)

Feladat 1; próbáljuk meg a 192.168.3.2 es gépről letiltani azt hogy mind2 webszerveren lévő weboldalakat meg tudjuk nézni mert az a felhasználó aki azon a gépen van egy hülye és ki szeretnénk tolni vele. Ha ez megvan próbáljunk meg még jobban kitolni vele és mondjuk arról a gépről mindenféle forgalmat letiltani a 2 webszerver irányába (de mind2 esetben csak és kizárólag a 2 webszerver irányába).
Első lépés a tervezés! Mint Mindig. Próbáljunk logikusan gondolkodni, első kérdés fel is tehetjük hová érdemes tennünk a szabályunkat? Az aranyszabály az, hogy próbáljuk megfogni a forgalmat amilyen hamar csak lehet, hiszen minek kóboroljanak a bitek ha úgyis letiltjuk őket... Ráadásul mivel a 2 webszerver külön alhálózaton van ezért a Debr1 és a Debr2 routeren is létre kéne hozni 1-1 ACL-t a siker érdekében de ha belegondolunk miért ne csinálhatnánk ezt meg a Debr3 nevű routeren? Ott kapásból megfogjuk a forgalmat ráadásul 1 helyre tudjuk tenni az összes ACL-t. Szuper, megvan a hely akkor essünk neki. Lássuk először a parancsot, és utána következik egy kis magyarázat:

Debr3(config)#access-list 105 deny tcp host 192.168.3.2 host 192.168.1.200 eq www
Debr3(config)#access-list 105 deny tcp host 192.168.3.2 host 192.168.2.200 eq www
Debr3(config)#access-list 105 permit ip any any

Majd pedíg:

Debr3(config)#interface fastEthernet 0/0
Debr3(config-if)#ip access-group 105 in

És ezzel meg is volnánk. Láthatjuk pingelni tudjuk a webszervereket, ám a weboldalak már nem fognak bejönni. Lássuk mit is csináltunk. Maga a parancs az „access-list”. A „105”-ös szám egy csoport azonosító mellyel hivatkozni tudunk majd erre az Access lista groupra. Értelemszerűen sok szabályt létre lehet itt hozni, és csoportosítani lehet őket, itt jön képbe ez az azonosító szám. Jó tudni hogy 1 től 99 ig számozzuk az úgynevezett standard ACL-eket és 100-tól 199-ig az úgynevezett Extended ACLeket. Hát a miénk most egy extended ACL lett és végig a 105ös számmal fogunk rá hivatkozni. A következő a deny/permit. Tiltjuk vagy engedélyezzük... a következő a „tcp” Itt leggyakrabban vagy a „tcp” vagy az „ip” szerepel, amikor „ip”-t írunk akkor az minden IP-s forgalomra vonatkozik majd amikor „tcp”-t írunk akkor itt később lehet majd definiálni részletesebben, hogy pontosan mit is akarunk letiltani (mondjuk 1 konkrét portot). A következő 2 rész az ,hogy HONNAN induló és HOVÁ menő forgalomra vonatkozzon ez a szabály. Jelen esetben nem alhálózat szinten (olyan példát is csinálunk majd) hanem gépenként tehát host szinten korlátozunk tehát a 192.168.3.2-es hosttól a 192.168.1.200as host felé. Mivel nem mindent szeretnénk letiltani csak a webes elérést (éppen ezért „tcp”-t választottunk) itt kell megmondani hogy mit is tiltunk le „eq www” minden „www”-vel egyenlő (eq) forgalmat ha szó szerint akarom írni, tehát gyakorlatilag a webes elérést. (ezt a www álca ez itt most csak a 80 as port lesz de később csinálunk port szerinti tiltást is) A második sor ugyanez csak az a másik webszerverre vonatkozik.

De mi is az a 3. sor (access-list 105 permit ip any any)??? Miért van az ott? Mi lehet az? Itt szeretnék elmondani néhány alapvető dolgot az ACL-ekről: Az ACL-eket sorokban képzeljük el. A szabályok föntről lefelé kerülnek vizsgálatra. Ha egy szabály érvényesül akkor a többi szabály már nem lesz figyelembe véve. Értsük ezalatt azt, hogy ha egyszer valamit letiltottunk vagy átengedtünk akkor az le van tiltva vagy át van engedve Függetlenül a lentebb található szabályoktól. Tehát olyan nincs hogy az első sorban valamit átengedünk, majd később letiltjuk! Akkor az már átment. Itt jön szóba a tervezés mivel új ACL sort mindig csak a lista végéhez tudunk hozzáadni!!!!!!! Tehát ha valamit átengedtünk és utólag jut eszünkbe hogy jajj azt mégis le akarjuk tiltani, akkor az a hajó már elment... És a legfontosabb dolog hogy az ACL lista végén mindig van egy képzeletbeli MINDENT letiltok MINDENFELÉ ACL szabály ha odatesszük ha nem. Ez úgy nézne ki leírva hogy „deny ip any any” vagyis –tiltani - minden IP forgalmat - bárhonnan jön-bárhová megy. Ennek értelmében próbáljuk értelmezni a 3adik sorunkat (access-list 105 permit ip any any). Mit szeretnénk elérni? Tiltsuk le egy hostról a 2 webszerver irányába a webes elérést de minden más menjen! Na, most ha a mi listánk végére a routerünk odateszi ezt a mindent tiltok mindenhová akkor nekem jól semmi nem fog menni, hiszen először letiltjuk a webes elérést a 2 szerver irányába, majd a router letilt minden minden irányba. Hát éppen ezért kell a 3adik sor a lista végére, „permit” – engedélyezz „ ip” – minden ip forgalmat „any” - bárhonnan jön „any” - bárhová megy. Ami a legérdekesebb hogy ettől nem tűnik el a „deny ip any any” sor az ACL végéről az mindig ott van, viszont mivel azt mondjuk hogy a szabályok felülről lefelé kerülnek vizsgálatra, és ha az egyik érvényre jut a többit már nem veszi figyelembe, akkor ezzel az engedélyező szabállyal gyakorlatilag kiütöttük a tiltást.

A legutolsó lépésként a szabályt hozzá kell rendeljük egy interfészhez, jelen esetben a fasthethernet 0/0 a fönti gépek alapértelmezett átjárója, tehát tegyük ide. Lépjünk be interfész konfig módba és a parancs mint fent láthatjuk „ip access-group” azonosító és „in” vagy „out”. Mivel itt a forgalom befelé jön vagy jönne ezért „in”. Ezzel az első példát ki is végeztük. Még egy nagyon fontos információ, ha mégis elrontanánk az ACL-jeinket, mondjuk a sorrendet, a legjobb ha megírjuk a helyes sorrendet egy notepadba, a meglévő ACL jeinket kitöröljük „no”-val és megcsináljuk előről az egészet (notepadból copy paste, csak pillanatok műve), de legyünk tisztába vele hogy meglévő listához új ACL szabályt mindig csak a lista legvégére tudunk hozzáadni!!!!!

Jöjjön a feladat „b” része amikor még jobban kitolunk a csákóvámmal és mindenféle forgalmat letiltunk afelé a 2 szerver felé, mert mondjuk ott egy ftp szerver is üzemel és mi jól letiltjuk neki azt is:

Debr3(config)#access-list 105 deny ip host 192.168.3.2 host 192.168.1.200
Debr3(config)#access-list 105 deny ip host 192.168.3.2 host 192.168.2.200
Debr3(config)#access-list 105 permit ip any any

Mivel itt gyakorlatilag minden ip-s forgaltmat tiltunk a listánk egy picit egyszerűbbnek néz ki, próbáljuk is ki hogy a 2 webszerver nem pingik, viszont mondjuk a PC0 az igen. Természetesen az interfészhez való hozzárendelést itt sem szabad elfelejteni.

Feladat 2; próbáljuk meg most letiltani az összes 192.168.3.0/24 es alhálózatban található gépről minden kimenő webes forgalmat. Ugye ez hasonló az előzőhöz, hova is lenne a legjobb lepakolni az ACL jeinket? Hát ismét csak a Debr3-ra.

Debr3(config)#access-list 105 deny tcp 192.168.3.0 0.0.0.255 any range 80 80
Debr3(config)#access-list 105 deny tcp 192.168.3.0 0.0.0.255 any range 443 443
Debr3(config)#access-list 105 permit ip any any
Debr3(config)#interface fastethernet 0/0
Debr3(config-if)#ip access-group 105 in

Használjuk ismét a 105 ös számot jó lesz az nekünk (mondanom sem kell ez pucér routerről indul tehát az előző feladatban lévő ACL eknek semmi köze ezekhez). Tiltsuk meg a „deny”- al ismét válasszuk a „tcp”-t a 192.168.3.0 ás alhálózatból fordított maszkal(!!) „any” tehát bármerre menő forgalmat ami a 80 as és a 443 as porton szeretne kimenni. Mivel minden másnak mennie kell ne felejtsük ez a lista végéről az engedélyező ACL ünket valamint az interfészhez való hozzárendelést.

Feladat 3; Hogy jobban megértsük a lista végén láthatatlanul szellemként kísértő automatikusan letiltok mindent szabályt nézzünk meg egy olyan példát hogy a „Debr3” routeren tiltsunk le minden kimenő forgalmat a 192.168.3.0/24 es alhálózatban lévő gépek szemszövégől nézve, egyetlen kivétellel mondjuk a 192.168.1.200 as szerveren lévő weboldalakat meg tudják nézni. Ez pl teljesen életszerű példa, úgy gondoljuk hogy az ott dolgozó embereknek nem szabad kijutni az ő kis hálózatukból nehogy túl sokat tudjanak, ámde mégis van egy webszerver amit el kellene érniük.

Debr3(config)#access-list 105 permit tcp any host 192.168.1.200 range 80 80
Debr3(config)#access-list 105 permit tcp any host 192.168.1.200 range 443 443

És ennyi. A történet megfordult, itt most tiltás helyett csináltunk 2 engedélyezést a 80 as és a 443 as porton minden mást pedig a router szépen letilt by default. Próbáljuk ki még csak pingelni sem tudunk sehová, a webszervert sem, viszont a rajta lévő weboldalt mégis elérjük.

Feladat 4; Próbáljuk meg most a 192.168.1.0/24 es alhálózatot (bal alul) teljesen eltüntetni a külvilág elől, tehát tiltsunk le mindent ami efelé az alhálózat felé jönne, egyetlen dolgot engedjünk meg hogy a 192.168.1.200 as webszerveren lévő oldalakat kívülről is elérjék. Hát úgy néz ki a leghamarabbi hely ahol el tudunk csípni minden forgalmat egy helyen az a Debr1 router belső lába (ez a f0/0ás interfész) hiszen ez az a láb amihez ha majd hozzárendeljük az ACL szabályainkat akkor bármilyen kívülről jövő forgalomra érvényesülni tud.

Debr1(config)#access-list 105 permit tcp any host 192.168.1.200 range 80 80
Debr1(config)#access-list 105 permit tcp any host 192.168.1.200 range 443 443
Debr1(config)#interface fastEthernet 0/0
Debr1(config-if)#ip access-group 105 out

Ugye itt most megengedjük, hogy a bárhonnan jövő forgalom a 192.168.1.200 as host irányába a 80 as és a 443 as porton bejöjjön egyébként meg hagyjuk hogy a router minden mást letiltson, és az acces listánkat hozzá pakoljuk a fastethernet 0/0-ához az irány pedig ebben az esetben kifelé mutat tehát „out”.

All in all egy komoly cégnél a 100 soros ACL lista szabályokat mindennaposnak vehetjük, ezért mindenképp tervezzük meg mielőtt belevágunk, fontoljuk meg mit hová tegyünk, és még egyszer kiemelve a szabályoknál a sorrend nagyon fontos. Elég felületesen érintettük csak az ACL-eket mert erről egy egész könyv is kevés annyit lehetne írni, ha valaki komolyan bele akar menni, rengeteg példa van a neten, utána lehet járni a lehetőségek tényleg korlátlanok.

DHCP

Természetesen ezeket a típusú routereket is rá lehet venni automatikus címkiosztásra. Persze ahol rettenetes nagy a security mondjuk egy nagyvállalati környezetben ott valószínűleg úgyis valami AD által ismert és hitelesített windowsos DHCP szerver fogja a címeket osztogatni. De ahol nincs ilyen követelmény ott ezek a routerek tökéletesek annál is inkább mivel egy ilyen routert bekapcsolsz beállítasz és gyakorlatilag 15 évig nincs vele baj még újraindítani sem kell.

Ennélfogva mivel az hogy egy kliens IP címet kapjon elég fontos és alapvető dolog ezért ezek az eszközök tökéletesek erre a feladatra. A DHCP beállítást a (config)# módban kell megkezdenünk és a parancs a következőképpen néz ki:

Router(config)#ip dhcp pool „és egy név”

Ezután egyből átkerülünk a DHCP konfigurációs módba.

A név azért fontos mert később a név alapján hivatkozhatunk majd egy adott DHCP pool-ra. Egy valódi routeren szinte minden DHCP-re vonatkozó tulajdonságot be tudunk állítani itt a Packet Tracer egy kicsit hiányos (pl nem tudunk címfoglalást vagy lease time-ot állÍtani benne, természetesen ezt egy normál routeren megtehetjük).

Adjuk meg most azt a hálózatot amiből a routerünk a címeket fogja osztogatni, emellett beállíthatjuk még a DNS szervereket valamint az alapértelmezett átjárót.

Ha azt szeretnénk hogy bizonyos címeket ne osszon ki a routerünk ebből az alhálózatból, mert mondjuk azt már odaadtuk statikusan egy szervernek, ezt is megtehetjük. Kintebb kell lépjünk a DHCP konfig módból és itt kiadni az „IP DHCP excluded-address” parancsot. Megadhatunk neki 1-1 IP címet is, de akár egy tartományt is. Ilyenkor a 2 címet és a 2 cím közötti IP-k közül semelyiket nem osztja ki.

Csinálhatunk címfoglalást is, bár ezt egy kicsit nehezebb megszülni, a packet tracer sajnos nem is tudja. Az elmélete az hogy egy új DHCP pool-t kell csinálni és nem a „network” paranccsal adunk meg egy alhálózatot hogy abból osztunk ki egy címet hanem a „host” paranccsal adunk meg egyetlen címet. Tudunk adni a kliensünknek egy nevet is, illetve megadni vagy a Hardware address-t (ez a MAC cím) vagy a client identifiert ami szintén a MAC cím csak máshogy kell elválasztani meg „01” el kezdődik de ha már ott tartunk a router ad segítséget a formátumhoz.

Az én igényeim a következőek voltak:
- Legyen szép, és webes.
- Tudjon levelekből jegyet nyitni (imap, pop3, ssl)
- Tudjon a ticketek állapotváltozásáról levelet is küldeni. (smtp, ssl)
- Legyen ügyféloldali webes felhasználókezelés
- Szép szagos kimutatásokat lehessen vele készíteni
- Linuxon és Mac Os X-en is lehessen mind a kiszolgáló részét, mind a kliens részét használni

Request Tracker

Először ehhez a PERL alapú open source toolra találtam rá. Azt kell hogy mondjam, hogy a beizzítása nem nehéz egyáltalán, de a mögötte ketyegő perl motort átlátni és kezelni azért macerás. A levelezésnél nem tudtam belőni az SSL SMTP-t, illetve külön fetchmail dolgozott alás a levelek feldolgozásából.

Sajnos ott halt el a project, amikor Mac Os X alá akartam integrálni. Akkor jött ki csak igazán ez a több lábból álló rendszer, amit ha nem kényelmesen csomagból raksz fel, akkor rendesen meg tud kínozni.

Ettől függetlenül tudom teljes mértékben ajánlani, mert a kicsit puritán design teljesen jól átlátható, és minden igényt kielégít, ezek mellett nagyon magabiztosan és kevés erőforrást emészt fel. A hivatalos weboldal megtalálható itt.

WebHelpDesk

Igazából nem volt bajom a Request Trackerrel, csak nem akartam megküzdeni a Mac Os X alá hegesztésével, illetve az azok utáni frissítésekkel. Magam se bíztam benne, de elkezdtem keresni Mac Os X-hez ajánlott issue tracker programokat. Valahol a sor végén leltem rá erre a megoldásra.

Támogatás

Ami számomra a legfontosabb volt, minden platform támogatott ami engem érinthet.

Maga a software egy web java servletben fut. Mivel a készítő cég teljes körű megoldást kínál ezért viszont az installer felrak egy saját tomcat servert, és abban indítja el. Tehát nem előfeltétel, hogy legyen tomcat már a gépünkön. Elég ha csupán telepítjük az installert.

Természetesen az én Mac Os X serveremben van külön tomcat, ebben az esetben felesleges a programhoz kínált környezet. Egyszerűen ki kell másolni a szükséges információkat, és már is elérhető saját tomcat-ünkön keresztül az alkalmazás.

Ezt a két mappát kell elmásolnunk a telepítés után a saját tomcat serverünkbe:

webhelpdesk/bin/webapps/helpdesk
webhelpdesk/bin/webapps/WHDReminderDaemon

Ezek után ha használunk apache-t is, akkor a következő két sorral tudjuk majd a webes forgalmat átirányítani tetszőleges URL-ről. (Ezt természetesen már nekünk kell testreszabni majd) A megfelelő virtualhost esetében helyezzük ezen sorokat az apache konfig file-ba (httpd.conf):

ProxyPass /helpdesk http://localhost:8081/helpdesk
ProxyPassReverse /helpdesk http://localhost:8081/helpdesk

Természetesen, ahogy annyi alkalmazás ez is igényel adatbázist maga alá. Ezt első indulásnál rá is kérdez. Amennyiben saját nem használunk saját tomcat servert, akkor lehetőség van a telepítővel felrakott FrontBase -t használni, illetve használhatunk a következők közül akármit:

• Windows SQL Server
• MySQL
• Oracle
• OpenBase SQL
• PostgreSQL

Csak megadjuk a megfelelő címet, adatbázis nevet, és hozzá tartozó felhasználónevet és jelszót a WebHelpDesk pedig már építi is fel magát.

Ezek után pedig máris használható a termék.

Licenselés

A másik nagyon szimpatikus dolog a licenselés volt. Ugyanis bizonyos korlátozásokkal használható teljesen ingyen, méghozzá időkorlát nélkül.

A legnagyobb veszteség amivel találkoztam eddig az az, hogy csupán egy nevesített technikusunk lehet. Ez az a személy aki az ügyeken dolgozik, olyan hozzáférése van. Ügyfelünk természetesen akármennyi lehet, ezzel a konstrukcióval is. Természetesen még más jelentős extra tudástól esünk el, de erről majd később.

Az admin felület

Belépéskor egy áttekinthető listás nézetet kapunk alapértelmezetten. Tudunk választani, hogy a saját jegyeinket akarjuk látni, a csoportunk jegyeit, illetve kereshetünk a jegyek között tetszőleges dologra. Minden lista esetében tudunk szűrési beállításokkal élni illetve, egy kattintással PDF illetve TSV dokumentumokat tudunk előállítani belőle.

Az admin felülethez a technikusok férnek hozzá Technikusokat csoportokba lehet foglalni. A csoportokhoz erőforrásokat tudunk rendelni. Erőforrásokhoz, több szintű technikusi csoportot. Tehát teljes és jól szeparált struktúrát tudunk felállítani a technikusainkból és a felmerülő problémákról.

Calendar

Tudunk egy naptár nézetet is kapni a ticketekről, a betervezett "to do"-król, és egy egyszerű feliratkozás segítségével (CalDav) ezt bármilyen lokális kliensünkbe is tudjuk integrálni.

Clients

Természetesen minden helpdesk központjában a felhasználók állnak. Lehetőségünk van dokumentumokból beimportálni felhasználókat, illetve magunk is vehetünk fel kézzel. A legjobb megoldás viszont, ha alapból LDAP-ot használunk, és egy tetszőleges csoportot definiálunk az LDAP-ban a Web Help Desk számára. Erre is van lehetőség.

Az ügyfeleknek engedhetjük vagy tilthatjuk, hogy levélben nyithassanak ügyeket, vagy updateljék azokat. Ha tiltjuk, akkor csak a webes felületen tehetik meg azt. Szélsőséges esetben azt is megengedhetjük, hogy új levél esetén automatikusan új felhasználót hozzon létre a rendszer.

A levelezéshez természetesen definiálnunk kell egy bejövő postafiókot, és egy kimenő smtp servert. Fontos és hasznos, hogy minden féle SSL és authentikálós módszert támogat a WHD.

Asset

Ez a funkció sajnos csak a fizetős verzióban elérhető. Itt viszont lehetőségünk van eszközöket definiálni. Így a jegyeket gépekhez köthetjük, vagy már a probléma megnyitásánál az ügyfél adott géphez, gépekhez tudja kötni a gondját. Ezzel viszont a technikus feladata gyorsul. Az Asset funckió által egy kattintással a megfelelő management toolt tudjuk alkalmazni. Legyen az RDP, ARD, VNC, akárni, és természetesen minden információt megtudhatunk az adott gépről vagy elemről már a WHD-ban, nem kell külön utána járnunk.

Parts

Szintén fizetős feature az Parts. Míg az Asset részen a működő rendszereket mint elemeket tároltuk, a Part-s alatt az egyéb kiszámlázandó, cserélendő alkatrészeket. Ugyanis a WHD nem csak arra jó, hogy hibát jelentsünk be, hanem új igényt is tudunk itt kérvényezni. Ilyenkor azt a megfelelő felhasználók jóváhagyják és akár egyből számlázhatják is, hála a WHD-nek.

FAQ

Aki dolgozott már hasonló munkakörben, az tudja jól, hogy bizonyos probléma újra és újra előjön máshol és máshol. Ilyenkor jó, ha egy egyszer jól körbeírt megoldást tudunk szolgáltatni fixen az ügyfeleknek. A FAQ (gyakran feltett kérdések) egy helyi tudás adatbázis. Ahova kérdéseket és válaszokat lehet felvinni. Ebben tudnak a technikusok keresni, és természetesen mindenki változtathatja, bővítheti a meglévő tudásbázist. Nagyon hasznos tud lenni, és szintén ehhez a toolhoz van alapból rendelve.

Reports

Természetesen minden főnök álma a kimutatások. Itt is van belőle, és nagyon változatosan és dinamikusan tudunk benne mozogni. lehetőségünk van fix reportokat csinálni, tetszés szerint is futtathatunk kimutatásokat, vagy időzíteni is tudunk. Ez hasznos lehet ha minden hónap/negyedév/év távlatában akarunk kapni kimutatásokat, de nem akarjuk észben tartani.

Messages

Lehetőségünk van jó feltűnő üzeneteket hagyni a társaknak. A rendszer is minden hibaüzenetet vagy kódról ide generál egy üzenetet. Így a különböző műszakoknak, könnyű lehet elkerülhetetlenül megjegyzést hagyni.

Setup

Itt tudunk minden előbb felemlegetett dolgot beállítani. Nem részletezném külön újra.

Ticket nyitása

Ahogy írtam külön feature, hogy az ügyfél levél által is tud nyitni automatikusan új ügyet. Viszont alapvetően, be tud lépni a WHD-be is, akor a következő felületet fogja kalni:

Itt tudunk jegyeket nyitni, a megfelelő kategórákat kiválasztva, asseteket, helyeket kiválasztani. A következő fülön követhetjük a már megnyitott jegyek történéseit:

Az Approval fülön kapunk eldöntendő kérdéseket. Olyan módosításokról, beavatkozásokról, amihez jóváhagyás kell az ügyfél részéről.

A FAQ-ban kereshetünk a technikusok által összeállított tudás bázisban, a Profile alatt pedig saját adatainkat tudjuk megadni, vagy megváltoztatni.

Összegzés

A WHD egy nagyszerű program, minden komolyabb és egyszerűbb igényt ki tud elégíteni. Rengeteg jó ötletet briliánsan egyesít egyetlen termékbe. Az ingyenes változat kisebb ügyfélkapu felépítésére tejesen alkalmas lehet a fizetős verziója pedig nagyszerűen tud alkalmazkodni a nagyok igényeihez is.

Bátran merem mindenkinek ajánlani, hogy nézzen utána jobban a terméknek a hivatalos weboldalon itt.

A routereken és switcheken többféle konfigurációs mód van és mindenhol más parancsok adhatók ki, így ha egy parancs nem működik szinte biztos, hogy a rossz konfig módban vagy.

Ha bekapcsolunk egy routert vagy egy switchet és már rá vagyunk csatlakozva az eszközre konzollal láthatjuk a bootolási folyamatot ami így néz ki:

Első alkalommal felajánl egy ilyen automata bekonfigurálós „varázsló” félét de erre inkább „nem”-et szoktunk nyomni és a későbbi manuális beállítást szoktunk előnyben részesíteni.

Konfigurációs módok

A cli-t mindíg úgy kapjuk meg alapértelmezetten, hogy:

Router >

Itt most egyenlőre a „Router” a routerünk hostneve. Mint fentebb írtam több féle konfigurációs mód van:

A konfig módok között különböző parancsokkal lehet közlekedni, a legelső konfig módból a másodikba lépni az „enable” paranccsal lehet. Az eredmény onnan látjuk hogy a kacsacsőr ikonunk „#” jelre változott.

Router#

Innen a következő konfigurációs módba a „counfigure terminal” paranccsal lehet belépni a sikert a következőképp látjuk:

Router(config)#

Innen többféle konfig módba lehet belépni attól függően hogy mit szeretnénk beállítani. Itt a képen végigkövethetjük ezt a folyamatot, oda vissza. A parancsok esetében nem fontos kiírni az egész parancsot, általában van egy rövidített változata is a hosszabb parancsoknak, úgymint „ena” és „conf t”... Kijjebb lépkedni az „exit” és végül a „disa” parancsokkal lehet. A parancsok kiegészítésesben segít a TAB billentyű (ha már a parancs egyértelmű) illetve ha még nem egyértelmű akkor a kérdőjellel megnézhetjük mit a lehetséges parancsok amik az adott karakterekkel kezdődnek. Ha semmilyen parancsot nem írunk be csak a kérdőjelet akkor az kilistázza az abban a konfig módban kiadható összes parancsot.

Ezek a konfig módok közötti lépkedések azért fontosak mert pl a legetső konfig módban nem tudsz IP-t adni egy interfésznek vagy nem tudsz jelszót beállítani a konzolra vagy nem tudsz routing protokollt beállítani, ezekhez egyel vagy kettővel beljebb kell lépjünk a konfig módokban.

Induló és futó konfiguráció

A routereknek és switcheknek 2 féle konfig file-juk van. Az úgynevezett running config és az úgynevezett startup konfig. Az eszközök újraindításnál mindíg a startup konfiggal indulnak el! Amikor pedig valamit mahinálunk, beállítunk az mindíg a running konfigba kerül. Ezek gyakorlatilag konfigurációs file-ok amik a router összes beállítását tartalmazzák. A lényeg az hogy ha csinálunk egy beállítást az minden esetben a running configba kerül, ám ettől az még nincs elmentve úgymond. Ha a routert újraindítjuk ez a beállítás elveszik, mivel a router mindíg a startup konfiggal indul el! Az aktuális konfiguráció mentése éppen ezért a következőképpen zajlik: első lépésként elvégezzük a beállítást ami belekerül a runing configba és második lépésként a running konfiggal felülírjuk a startup konfigot. Úgy is mondhatjuk hogy ha menteni akarjuk az aktuális változásokat akkor rendszeresen szinkronizálni kell az aktuálisan változó running confogit és azt a konfig fájlt amit a router az elindulásnál használ. Ha a másolást megtettük, és a routert újraindítjuk, gyakorlatilag a startup konfig tartalmazni fogja azokat a beállításokat amiket a running configba mi megcsináltunk és pontosan ugyanazokkal a beállításokkal fog elindulni. Ezt nevezzük mentésnek.

Ugyanakkor ez egy hatalmas menekülési lehetőség is, ha eltoljuk(elbasszuk) a konfigurációt és elkezd semminemműködni, egyszerűen ujraindítjuk a routert, és minden az addíg csinált beállításunk elvész, a router elindul a még működő beállításokat tartalmazó startup konfiggal és gyakorlatilag meg vagyunk mentve.

A konfiguráció mentése a „#” jelő módban végezhető el a „copy running-config startup-config” parancsal. (copy run start)

Debrl# copy run start

Itt rákérdez a destination file-névre itt gyakorlatilag a startup-config és a running-config ez ténylegesen konfigurációs fileok neve, ezen célszerű nem változtatni így egy enterrel megerősítve a mentés kész is.
Ezeket a konfigurációkat elég gyakran szoktuk nézegetni, főleg a running konfigot... Általában minden „lekérdezést” a show paranccsal csinálunk. Az aktuálisan futó konfigurációt a „show running-config” parancsal nézhetjük meg (sh run). Hasonlóképpen mint a startup konfigot (sh start).

Nézzünk pár beállítást és parancsot

Nagyon fontos ezért írom az elejére, ha valamilyen parancsot vissza akarunk vonni, vagy törölni szeretnénk akkor általában elé írjuk a „no” –t és beírjuk még egyszer a parancsot. Ez általában törli a beállítást. Itt egy példa, amiben látszik, hogy a parancs szerkezete ugyanaz egyszerűen csak elé írtuk hogy „no” és a beállítás máris törlődött:

A routert a „#” jeles módban lehet újraindítani a reload paranccsal (előtte ne felejtsük el menteni az aktuális konfigot hacsak nem épp az a cél hogy az újraindítássál töröljük az esetleg balul sikerült változásokat..

Hostname

A routerünknek célszerű megváltoztatni a nevét hogy amikor belépünk felismerhető legyen. Ezt a conf t-s mádban lehet megtenni a hostname paranccsal. A formátuma „hostname” és utánaírjuk a kívánt nevet:

A sikert máris láthatjuk az utolsó sorban megváltozott a routerünk neve.

Banner

Szinte minden eszközben be van állítva egy banner, amit ha beépünk az eszközbe elolvashatunk. Itt általában nem üdvözlő szöveget szoktuk beállítani hanem egy sablonszöveget hogy ha nem idevaló emberke vagy akkor lépj ki mert ezzel megsérted a bla..bla...bla...

A parancsot a (config)# üzemmódba lehet kiadni ( a szöveget a „c” karakterekkel kell közrefogni):

Debr1(config)# banner modt c „ide jön a szöveg” c

Amint újraindítjuk a routerünket máris láthatjuk a bannerünket.

Kivéve persze ha kihagytuk a „copy run start” parancsot ha ezt kihagytuk és a routert újraindítjuk a running configba kerülő beállításaink mentése nélkül az eredeti startup konfig töltődik be ahol ez a konfiguráció még sehol nem volt így nem lesz bannerünk... Ezt meg kell szokni. Kisebb és biztosan működő változások után menteni!!!

Interfészek

Ha ránézünk a routerünkre vagy a switchünkre kívülről kapásból láthatjuk milyen interfészeink vannak. A routeren belül ezt a „sh interfaces” paranccsal tehetjük meg a „#” jeles konfig módban. Ezzel az összes interfész összes tulajdonságát megláthatjuk... szép hosszú lista.

Ha csak egy interfészre vagyunk kíváncsiak akkor konkrétan meg kell neveznünk az adott interfészt is mondjuk „sh int f0/0” amivel most a 0/0-és fastethernet interfész tulajdonságait kérdeztük le.

Ez a kép rengeteg információt mond el nekünk az áthaladó csomagokról az interfész státuszáról stb...
A legelső sorban már mindjárt láthatjuk hogy F0/0 is Administratively down. Ezt azt jelenti hogy az interfész az operátor által (azaz általunk) le van kapcsolva. Ez azért van így mert mindig ez egy interface alapértelmezett státusza. Ha egy interfész működik és van kapcsolata akkor a státusza egyszerűen „up”, ha pedig a vonal megszakadt és nincs kapcsolata akkor egyszerűen „down”. Ha pl ez van akkor feltételezhetjük hogy megszakadt a bérelt vonal, vagy kihúzták a switchből a kábelt, vagy esetleg lekapcsolták a switchportot stb...

Az interfészünket fel le tudjuk kapcsolgatni a „shutdown” és a „no shutdown” parancsal. Nagyon fontos mégegyszer ha egy parancsot vissza akarunk vonni akkor eléírjuk a „no” –t beírjuk ugyanazt a parancsot amit kiadtunk ezzel visszavonva azt. Mivel itt az interface alapesetben shutdownolva van ezért a no shutdown parancsal tudjuk életre kelteni. Ezt már interface konfigurációs modban tudjuk megtenni! Ahoz hogy egy interface tulajdonságait állítgassuk annak a konkrét intercafe-nek kell belépnünk a konfig módjába jelen esetben ez a fastethernet 0/0 interface:

Debr1(config)#int f0/0

Itt a packet tracer egy kicsit csal, egy igazi routeren miután kiírja hogy „changed state to up” utána egyből ki is írja nekünk hogy „changed state to down”. Miért is van ez? Mert nincs a másik oldalon semmi még. Felkapcsoltuk, ő megnézte magának hogy él e a link, mivel most még nem kötöttük össze semmivel ezért ő le is kapcsolja magának az interfészt. Mivel a Packet Tracer szoftver azért annyira nem „live” ezt nem láthatjuk, de azért ha megnézzük az interface állapotát láthatjuk hogy nem „up” ba hanem „down”-ba van. Amit megfigyelhetünk hogy ez már nem „administratively down” hiszen az interfészt felkapcsoltuk. Amint összekötjük valamivel, automatikusan „up” ba kerül. Ha az interface „administratively down” állapotba van, vagyis gyakorlatilag letiltva addig nem fog „up”-ba kerülni amíg fel nem kapcsoljuk hiába kötjük össze a másik oldalon lévő eszközzel.

Csak érdekesség képen nézzük meg milyen parancsokat lehet kiadni interfész konfig módban, itt már nem olyan hosszú a lista... nyomjunk egy kérdőjelet és megkapjuk a kiadható parancsokat.

Adjunk az interfészünknek egy IP címet:

Ezt az „ip address” parancsal tehetjük meg. Az ip beállítás után, ha még nem tettük meg ne felejtsük el felkapcsolni az interfészt.

Nézzük meg hogy mit műveltünk. Mivel azt mondtuk, hogy a változások a running config-ba azonnal belekerülnek így itt már látnunk kellene a beállított interface tulajdonságainál az új IP címet.

És lám tényleg:

Nyomjunk egy „sh run” parancsot!

Ahhoz hogy az alapvető dolgokat megértsük, akkor most nyomjunk egy „sh start” parancsot is az induló konfiguráció lekéréséhez.

Hoppá, itt miért nincs IP címe az interfésznek? Hová lett? És a Running configban miért van? Akkor most nem ugyanaz a kettő vagy mi? Hát nem... Mint ahogy már korábban leírtam, az aktuális beállítások a running configba kerülnek. Amíg ezt el nem mentjük a startup konfigba is addíg bizony nem ugyanaz a 2 file. Ha most jön egy áramszünet akkor az IP címünknek kakukk, de amint kiadjuk a „copy run start” parancsot és lekérjük a startup konfigot már ottis pontosan ugyanazt fogjuk látni, mint a running configban. Ne felejtsünk elmenteni!!

Két fastethernet vagy gigabit ethernet vagy akármilyen ethernet port közötti kapcsolatnál, legyen az router-router vagy router-switch között az IP cím beállításával (mind2 oldalon) és az interfészek felkapcsolásával máris „up” ba kerülnek az interfészeink. 2 router közötti serial kapcsolatnál annyi dolgunk van még hogy az egyik oldalnak órajelet kell adni amit a „clock rate” paranccsal tehetünk meg.

Interface Description

Egy nagyon pici ámde annál lényegesebb rész. Lehet jobb is hogy kihagytam a „nagy” interface topicból, talán így jobban felfedezhető hogy egy külön kis topic. Minden egyes interfészhez egyedileg tudunk egy kis description mezőt fűzni. Ha ezt nem tesszük meg, később majd ott bogarászhatunk hogy melyik interfészünk melyik kapcsolathoz is tartozik főleg ha sok ugyanolyan típusú interfész van ami abszolút nem kizárt sőt... Amint beállítunk egy interfészt írjunk hozzá egy kis szöveget hogy milyen kapcsolatot van azon az Interfészen, pl „Tatabánya Internal Lan”, vagy „Budapest-Debrecen invitel 20Mb”. Mivel ez a tulajdonság az egyes interfészekre egyedileg vonatkozik ezért természetesen interfész konfig módban kell ezeket megtennünk. A parancs a következő: description „és a szöveg”.

A „#” jeleknek semmi különös funkciója nincs, egyszerűen csak sokkal jobban észre lehet venni, ami azért jó mert amikor lekéred a konfigurációt gyakorlatilag ez az a mező amit elsőnek megkeresel egy interfészen.

Lássuk mit csináltunk:

Az interfész jellemzői között szépen láthatóan ott van hogy milyen kapcsolat van rajta. Tökéletes.

Miből áll egy Open Directory?

Az Apple nagyon sok technológiát és innovatív gondolatot vett át a SUN-tól. Ilyen a Directory Server filozófia is. Ez nem egy teljesen új dolog, csak a meglévő komponensek egyesítése és rendszerbe foglalása. Be kell látni a Linux/UNIX világnak, hogy nagyon jó technológiák állnak rendelkezésre, de mivel nincs valamiféle szabványos eljárás, ezek kapcsolataiból, struktúrájából annyi féle van, ahány üzemeltető létezik. Az Open Directory (vagy SUN esetében Directory) szerver meglévő alkalmazások/programok csoportba foglalása, és valamilyen standard létrehozása. Ez az amit a Microsoft már régen meglépett az Active Directory-val (rövidítve AD), és azóta is nagy siker követi ezt a technológiát. Nézzük is milyen elemekből épül fel az Open Directory (rövidítve OD).

- LDAP
- Kerberose
- Password Server

LDAP

Ez egy rövidítés. Lightweight Directory Access Protocol azaz "pehelykönnyű könyvtár hozzáférés protokoll". Egyszerűen mondva egy olyan fa struktúrán alapuló adatbázis ahol tipikusan gyorsan kell keresnünk, és sok kis információt akarunk benne elraktározni. Íme egy kis ábra arról a filozófiáról amit az LDAP vall:

Jól látszik a fa struktúra. Fent van a gyökér elem (ahonnan a fa kinő ez a kezdő pont). Minden zöld elemnek kell hogy legyen Distinguished Name-je (rövidítve DN), azaz egyedi megkülönböztető neve, amivel hivatkozhatunk rá.

Ezek a DN-ek tartalmazhatnak minden féle rövidítési tagot. A fenti példában is jól látszik ahogy "dc=", "cn=" értékekkel nevesítsük a levél elemeket. Ahhoz hogy egy levélelemet meg akarunk hivatkozni, akkor a teljes DN-jét meg kell adnunk. A fenti példában például: "uid=anne, cn=users, dc=example, dc=com" DN-el hivatkozzuk meg Anne Johnson bejegyzését. Lehetőségünk van relative distinguished name (rövidítve RDN) megadására is, amikor nem a gyökérelemhez viszonyítva adjuk meg a helyzét a másik elemnek.

Az LDAP tehát egy gyorsan kereshető címtár. Ahol strukturáltan tudunk információkat tárolni. Itt tárolódnak majd a számítógépeink minden kapcsolódó információval együtt, a felhasználóink csoportjaink. Az LDAP jól ismert a Linux/UNIX világban, és természetesen az Open Directory LDAP-al is lehetőség van bármely olyan a külső alkalmazást használni ami a normál LDAP standard kapcsolódást támogatja

Kerberos

A kerberosnak kettős feladata van. Első sorban egy központi megbízható hitelesítési csomópontot jelent mindenki számára, másrészről viszont jegykiszolgáló feladatot is lát el. A hitelesítéshez ugye minden féle kulcsokat cserélgetnek, és információkat titkosítónak a résztvevő tagok. Ez bonyolult hálózat esetén hihetetlen szövevényes utakat jelenthetnek, és mindig kérdéses lesz az, hogy az akivel kommunikálni akarunk, az mennyire megbízható. Így jött létre a kerberos technológia, ami egy központi megbízható hitelesítést tesz elérhetővé. Ez a Key Distribution Center (röviden KDC).

Másod sorban lehetőség van jegyrendszer szolgáltatásra is. Ekkor van egy KDC és egy szolgáltatás ami kerberose támogatással bír és természetesen van egy felhasználó, aki a szolgáltatást kívánja igénybe venni:

Először a felhasználó a KDC-hez fordul, és hitelesíti magát. Ez ez első két nyíl. Majd amikor ez megvan akkor külön kér engedélyt ahhoz a bizonyos servicehez, ami valahol távol fut. Amennyiben van hozzáférése a KDC kiállít egy jegyet neki. Ez a hármas és négyes nyíl. Az ötös hatos lépésben a kliensünk ezzel a jeggyel felkeresi a használni kívánt service-t, aki ezt a jegyet érvényesíti magánál, és engedélyezi a felhasználónknak a használatot.

Tehát a kerberos a biztonságos és centralizált hitelesítésért felelős az OD-ben.

Password Server

Ahogy a nevéből is következik ez a komponens a jelszavak tárolásáért felel. A jelszavak a rendszerünk legfontosabb elemei. Ezeket megfelelően kell tárolnunk, és biztosítanunk azt, hogy a felhasználók ne juthassanak senki más jelszavához. Lehetőség lenne a jelszavakat az LDAP struktúrában tárolni, de külön szeparált komponensként így nagyobb biztonságot lehet garantálni.

A password server egy 128 bites azonosítót rendel hozzá minden egyes jelszóhoz, a jelszót pedig típusa szerint vagy visszafejthető (plain text) vagy titkosított (encrypted) formában tárolja a saját adatbázisában. Természetesen a password server a jelszavakhoz minden féle információt le tud tárolni. Úgy mint honnan használták és mikor utoljára sikeresen vagy sikertelenül.

Íme a táblázat arról, hogy a Password Server milyen típusú authentikációkat, hogy kommunikál a hálózaton, illetve hogyan tárol el.

Tehát a Password Server komponens felel a biztonságos jelszó tárolásért és jelszó kiadásért.

Open Directory típusok

Tehát már tudjuk, hogy az OD nem más mint egy csoport komponensből álló egység, ami a jelszókezelést, hitelesítést és címtár szolgáltatást rejt magában. Az Mac Os X Server viszont csak mint Open Directory kezeli ezt a szolgáltatás halmazt.

Alapvetően minden előzetes beállítás nélkül a serverünk Standalone állapotban lesz. A jövőben is lehetőség van visszaállni erre a helyzetre. Ez gyakorlatilag az Open Directory hiányát fogja jelenteni, ilyenkor simán a UNIX-os file alapú minimális szolgáltatás áll rendelkezésünkre.

Open Directory master-ről akkor beszélünk, ha a kinevezett gép látja el a fent tárgyalt három funkciót. Az adatok olvashatóak és változtathatóak is ezen OD-n keresztül.

Open Directory Replica ahogy az a nevéből is következik egy másolat. Értelem szerűen ahhoz, hogy replikát használjunk kell, hogy már legyen egy Open Directory Master-ünk. Ilyenkor egy másolat jön létre egy másik szeparált rendszeren az egész OD-ről. Természetesen a master és a replica között folyamatosan fent áll a kapcsolat. Ha ez mégse történne meg (kiesés vagy hálózati hiba), akkor amint újra helyreáll a kapcsolat a replica leszinkronizálja magát.

Fontos hogy egy replikára csatlakozva lekérhetőek az információk, authentikálni is lehet róla, de módosítani, felvinni, törölni adatokat nem lehet, csak és kizárólag a Masterre. Ez az alkalmazás telephelyek esetén jó megoldás tud lenni, egy "read only Active Directory"-hoz hasonlóan tud funkcionálni. Amennyiben a master-en helyreállíthatatlan kár történne, mindegyik repilákát "elő lehet léptetni" OD masterré.

Open Directory Master inicializálása

!!!FONTOS!!! Az Open Directory service megköveteli, hogy az Open Directory-ban definált Search Base (az LDAP gyökér eleme, ami a server host nevéből származik) a DNS servere által elérhető legyen és a gépünk által használt IP-re mutasson. Ha ez nem lenne meg, elég komoly problémákba fogunk futni.

Amennyiben Standalone állapotban van a gépünk, akkor kattintsunk a CHANGE gombra, ahol a következő ablakokban kell a megfelelő adatokat kitölteni.

Először is meg kell adnunk egy Directory Administrator-t. Annak username-ét, UID-ját, és jelszavát. Alapból felajánlja az első hármat, érdemes is elfogadni. Jelszót pedig elég bonyolultra és erősre érdemes választani, ugyanis ez a felhasználó lesz a korlátlan ura az egész OD-nek.

A következő ablakon már csak a Kerberos REALM-et kell definiálni és az LDAP Search Base-jét. Ezeket is automatikusan felajánlja a varázsló a gépünk host nevéből származtatva. Különleges igények nélkül érdemes is elfogadni.

Ezek után már csak egy összegző képernyőt kapunk, és el is készült az Open Directory Master szervizünk.

Open Directory Replica iniciálása

Amennyiben létre akarunk hozni egy replikát, fontos hogy legyen egy működő már inicializált OD master-ünk. Az OD master és a leendő replika között fontos, hogy a következő portok nyitva legyenek:

Open Directory Master gépen:

22 - SSH
311 - Password Server
389 - LDAP
636 - Secure LDAP

Open Directory Replica gépen:

311 - Password Server
389 - LDAP
636 - Secure LDAP

Amennyiben ezek a dolgok nem lesznek előkészítve a OD replika varázsló ablaka meg fog akadni és hibásan fog létrejönni a OD replica, ami természetesen teljes mértékben használhatatlan lesz.

Ahogy fent látszik az OD masternél az SSH portot is ki kellett nyitunk. Természetesen arról is gondoskodnunk kell, hogy az SSH fusson is az OD master gépünkön. Ehhez válasszuk ki a Server Admin Tool-ban a serverünket. Menjünk a Settings fülre, majd ott General tab alatt pipáljuk be az SSH-t. Ezzel el fog indulni maga az SSH, de még azt is ellenőriznünk kell, hogy root-ként is be lehessen lépni. Ez egy elég nagy biztonsági rést jelent, de arra a rövid időre amíg a replika elkészül szükséges. Ezt a Server Admin Tool-ban a master servert kiválasztva, a Settings fülön az Access menüben tudjuk megtenni.

Amennyiben ezen elő követelményekről gondoskodtunk indítsuk a replikának kijelölt gépen a varázslót és válasszuk a replika létrehozását.

Meg kell adnunk a OD master IP-jét vagy host nevét, és a master jelszót. Ez a master jelszó megegyezik a telepítésnél először megadott helyi felhasználó jelszavával. (gyakorlatilag a root jelszava). Továbbá a OD masteren létrehozott Directory Administrator user neve és jelszava szükségeltetik. Ezek után ha minden rendben van, akkor indul is a replikáció.

Ha ez a csík huzamosabb ideig nem akar mozdulni (5 percnél tovább), akkor biztosra vehetjük, hogy valamilyen port nincs kinyitva megfelelő képen.

Amennyiben viszont mindent megfelelően tettünk, akkor a következő képernyőt kell kapnunk:

Ha minden rendben van, akkor a Server Administrator Tool-ban az Open Directory menüpontban valami hasonlót kell látnunk:

Természetesen a replica "read-only" tulajdonsága miatt itt több fül is inaktív lesz, mivel ez csak egy replika.

Open Directory replica változtatása

Ahogy említettem nem áll meg az élet az OD replica esetén sem. Amennyiben egy replica fut az adott Mac Os X Server-en úgy lehetőség van visszaállni (lebutítani) egy sima Standalone változatra, vagy a meglévő adatokat felhasználva előléptetni OD master-ré. Ezen felül pedig lehetőségünk van még OD nélkül csak egy meglévő master-hez csatlakoztatni a gépünket.

Ilyenkor meg kell adnunk a master jelszót, illetve a Directory Administrator username-ét és jelszavát. A replika ilyenkor ugyan úgy mint a létrehozásakor SSH-n felkeresi a master-t, és szépen kiregisztrálja magát a központból.

Open Directory Struktúra

Akkor most essen pár szó a struktúráról. Sajnos fájó, de csak egy OD master lehet a struktúránkban. Egy OD masternek maximum 32 darab replikája lehet. Ezt azzal lehet fűszerezni, hogy a replikákból úgynevezett replica realay-ket hozhatunk létre amiből szintén 32 lehet, de ezek alá újabb 32 replikát tolhatunk be, így a dokumentáció szerinti maximális szám 1056 tud lenni. Nem hinném, hogy ennyire bárkinek is szüksége lehetne.

Ami igaz az igaz, ez számomra is egy fájó pont egy egyszerű Microsoft Active Directory-hoz hasonlítva. Ez az egy master tagból álló rendszer eléggé megköti a lehetőségeket, és korlátozza az adminisztrálási, vagy feladat/jogkör leosztási lehetőségeket. Remélem a jövőben ezen majd változtat az Apple, és felzárkózik tudásban a konkurencia mögé.

Természetesen nem kell megijedni, Windows-al szemben itt lehetőségünk van, több OD struktúrához is egyszerre kapcsolódni egy klienssel. Így végül is ha nem is adminisztrátori megoldással, de könnyedén tagjai tudunk lenni több domain-nak is.

Open Directory CLI - Command Line Interface

Akkor had jöjjön pár tipp, ahhoz hogy tudjuk debugolni, vagy egy egyszerű terminál segítségével vezérelni az Open Directory-nkat. Sajnos sok esetben szükséges, mert kis figyelmetlenséggel könnyű olyan állapotba kergetni az OD-t, hogy onnan a szép grafikus admin tooljaival az életbe ne lehessen kihozni.

Először is a legfontosabb, amit ha hamarabb tudok, nem kell kétszer is újra telepíteni az egész Mac Os X Server-t, hogy bármilyen összehugyozott állapotában, hogyan lehet törölni egy OD mastert, vagy replikát.

# slapconfig -destroyldapserver

Nézzünk még pár hasznosat:

# slapconfig -getstyle
Megmondja, milyen OD beállítás van használva.

# slapconfig -getmasterconfig
Kirajzolja az adott struktúrát, a kapcsolódó replikákat és azok állapotait. (Master-on kiadandó)

# slapconfig -getreplicaconfig
A replikán kiadva kiírja a master elérhetőségét és az utolsó szinkronizáció idejét.

# slapconfig -getldapconfig
LDAP alap beállításainak listázása.

# slapconfig -getmacosxodpolicy
OD Policyk lekérése.

# slapconfig -createldapmasterandadmin "new admin" "new fullname" "new uid" [

A DIM_Stat a szerver komponense a terméknek. Alapvetően képes minden féle Linux/Unix teljesítmény méréssel kapcsolatos kimenetet feldolgozni (vmstat, mpstat, iostat, stb.). Mégis az igazi előnye abban van, amikor a kliens komponenst is használjuk, aminek STATsrv a neve.

A kliens egy tetszőleges porton (alapértelmezetten ez az 5000) hallgat, és természetesen minden féle teljesítmény monitorozó scriptel el van látva. Ezen a porton szólíthatja meg a klienseket a szerver. Olyan időközönként, ahogy szeretnénk. A lekért adatokat pedig minden szerverről, minden időben egy központi MySQL adatbázis fogja elraktározni.

Ezek után, hogy központilag tárolunk minden alkalmunk válhat minden féle elemzés, kiértékelés futtatására. Ezeket táblázatosan, illetve grafikusan (akár JAVA applet formában) is kigeneráltathatjuk. Tetszőleges számú, időintervallumú, illetve paraméterű grafikonokat, vagy kiértékeléseket hajthatunk végre ezzel.

A DIM_Stat és STATsrv egy francia SUN alkalmazott magán projectjeként kezdődött, mára viszont a SUN is átvette és ajánlja az alkalmazást. Teljesen ingyenes, Solaris, Linux-on tökéletesen alkalmazható, centralizált teljesítmény elemző alkalmazás.

DIM_stat telepítése

A DIM_stat-ot telepíthetjük Solaris-ra és Linux-ra is. Saját installert használ, és sajnos saját webservert és saját mysql instance-t fog használni. Erre figyeljünk ha már futtatnánk ezekből, akkor amennyiben nem választunk a DIM_stat-nak másik portot akkor könnyen összeakadhatnak. Linuxon és Solarison teljesem megegyezik amúgy a telepítés menete.

Töltsük le a megfelelő installer-t és tömörítsük ki:
# gunzip -c dim_STAT-v85-solaris-x86.tar.gz | tar -xf -
# ls -lah

Lépjünk a kitömörített könyvtárba és indítsuk el az installert:
# cd dim_STAT-INSTALL
# ./INSTALL.sh

Az installer kiírja nekünk a gép hostnevét és IP címét, amit jóvá kell hagynunk. Ezek után meg kell adnunk az alkalmazás felhasználóját és csoportját. Ha nem létezne, akkor a telepítő rákérdez, hogy létre hozza-e.

Ezek után jóvá kell hagynunk azokat a könyvtárakat ahova a DIM_stat a komponenseit telepíteni fogja. Ha ez is megvan, egy összegző listát kapunk a beállításokról.

Ha ez is megvan elkezdődik a telepítés, és siker esetén már a promptot fogjuk visszakapni. A megfelelő rc scripteket is létre fogja hozni ha kérjük, tehát újraindítás esetén is automatikusan el fog indulni.

A DIM_stat, szerver komponens elindításához már csak a következőket kell tenni:

# cd /app/ADMIN
# ./dim_STAT-Server start

STATsrv telepítése

Akkor nézzük a kliens komponens telepítését. Én Solaris-ra telepítetem, de LINUX-os csomagok is elérhetőek. Amennyiben letöltöttük a megfelelő csomagot, csak a szokott módon telepítenünk kell.

# pkgadd -d STATsrv-Sol10-x86.pkg

Elindítani pedig szintén egy egyszerű paranccsal tehetjük:

# /etc/STATsrv/STAT-service start

Ekkor már fut is, és lehet hozzá csatlakozni az 5000-s porton.

DIM_stat

Ha már minden telepítve van, akkor kezdjünk neki a konfigurációnak. Csatlakozzunk a böngészőnkel a DIM_stat serverünk IP-jére (vagy host nevére):

Minden szükséges link, és dokumentáció elérhető az oldalon, de a tényleges DIM_stat menüje a WELCOME menüpontra lesz elérhető.

Alapvetően két nagyobb rész különböztethető meg. A felső rész az automatizált feldolgzással kapcsolatos menüpontokat rejti, míg az alsó a minden féle file műveletben segíthet. Itt tudunk statikus file-okat is beimportálni, illetve lehetőségünk van törlésre, módosításra.

Automatizált Teljesítmény kiértékelés

Mivel telepítettünk egy kliens komponenst így most nézzük, hogy vehetjük azt ide fel. Menjünk a START NEW COLLECT menüpontra. Itt egy listát fogunk látni a már felvett hostokról. Illetve a new menőzbe kell írnunk azt, amit újként kívánunk felvinni. Zöld jelzi azt, ha kitűnően működik, piros azt ha nem.

Természetesen le tudunk állítani hostokat, illetve törölhetünk is, ezekhez természetesen a fő menüben külön menüpontok tartoznak.

Amennyiben elég ideje gyűjti az információkat a DIM_stat, akkor az ANALYZE menüben tudunk kiértékeléseket generálni.

Lehetőségünk van egy hostról több paramétert összehasonlítani, illetve több hostról ugyan azokat a paramétereket. Nézzük először single host esetén:

Egy listát kapunk az elérhető hostokról illetve arról miből mennyi adat gyűlt össze róluk. Válasszunk hostot, majd bökjünk rá arra a gombra, aminek a kiértékelésére kíváncsiak vagyunk. Én most a VMSTAT-ot választom.

Ezek után kapunk egy nagy táblázatot sok-sok beállítási lehetőséggel. Ki tudjuk választani milyen időintervallumban, illetve mennyi adat legyen kiértékelve. Külön kiválaszthatjuk, hogy milyen paramétereket akarunk szövegesen látni, táblázatba foglalva látni, és grafikusan kirajzolva. A grafikus esetben választhatunk, hogy JAVA vagy kép alapú megjelenítést kérünk.

Ami a szép ebben, hogy azt, és úgy rajzoltatunk ki vele, amit csak akarunk.

Nézzünk, most egy multi host kiértékelést:

Itt nincs lehetőség szöveges adatokra, csak azt kell kiválasztanunk, melyik hostra vagy hostokra vagyunk kíváncsiak, és mely paraméterek alapján kérünk rajzokat.

Íme egy példa arról mit lehet így generálni:

Összegzés

A DIM_Stat és STATsrv nagyon jó alapokból építkezik. Kicsit fapados, látszik a mély dolgokra több időt és energiát szenteltek mint a használhatóságra. A server kliens alkalmazások sajnos sok esetben le tudják nagyon terhelni a gépet, viszont ésszel kell vizsgált paramétereket választani, és megfelelő lekérdezési intervallumot beállítani.

Sajnos sokszor elvesztem a rengeteg paraméterben, ami kiválasztható, és ha valaki nem ismeri eme paraméterek mögöttes jelentését, akkor nem tudja milyen grafikont vagy érték táblázatot is fog kapni. A tool maga amúgy szuper, hihetetlen nagy előrelépést tud jelenteni a teljesítmény monitorozásban. Én magam részéről maradok a (K)SAR megoldásnál.

Akit részletesebben érdekel a tool, és a lehetőségei az a hivatalos oldalt elérheti itt.

Természetesen nagy szükség van arra, hogy az ember hivatalosan, vagy nem hivatalosan, de pártatlanul fel tudja mérni a tudását. A következő pontokat gyűjtöttem össze, ami számomra elvárás lenne a tudásom felmérésével kapcsolatban.

- Témakörönként tudjak több kérdést felvinni.
- Témakörönként lehessen választani hány kérdést válasszon ki nekünk a teszthez. Ezt természetesen véletlenszerűen tegye.
- Egy kérdésen belül lehessen véletlenszerűen kiválasztani a válaszok sorrendjét, hogy biztos tudjam a kérdésre a választ és ne csak megszokásból válasszam ki.
- Kérdéseket lehessen besorolni nehézségi szint szerint.
- Lehessen kimutatásokat futtatni, ami ki tudja mutatni időről időre, hogy hogyan teljesítek.
- Server Kliens alapú legyen, és lehetőleg amennyire csak lehet multiplatformos.

iTest - a megoldás

A fenti elvárások szerint elkezdtem keresni létező megoldásokat. A multiplatform miatt alapvetően WEB-es alkalmazásokat néztem, de azt kell hogy mondjam valahogy mind "gagyi" volt. Legnagyobb megdöbbenésemre, egy Mac Os X oldalon akadtam rá erre a programra.

Ez a teljesen nyílt, és ingyenes program elérhető Windows, Linux, Mac Os X-re is.

A telepítő minden esetben felrakja nekünk mint a server mint a kliens alkalmazást is.

A server

Kezdjük akkor először a serverrel. Ha megnyitjuk az alkalmazást a következő kép fogad majd minket:

Ahhoz, hogy elkezdjük a produktív munkát létre kell hoznunk egy adatbázis file-t. Ebből természetesen használhatunk többet is. Mindig az aktuálisan megnyitottal fogunk tudni dolgozni. A piros színnel jelzett menü ikonok az adatbázis file-hoz tartoznak.

A Sárga rész a szerverünk által nyújtott szolgáltatások sorát jelzi. Egyszerű fülekként (tab) funkcionálnak. Attól függően melyiket választjuk ki a lenti rész úgy változik meg. Alapértelmezetten a Questions rész az aktív, ez látszik a screenshoton is. Ilyenkor van lehetőségünk a bal oldali hosszú menürészbe felvinni kérdéseket. A felvitel (törlés és módosítás) vagy a felső menüsor zöld keretével tehető meg, vagy a baloldali kérdést gyűjtő mező alatt lévő apróbb gombok segítségével.

Ha egy kérdést felviszünk vagy módosítunk, akkor a mellette lévő nagyobb részen kell definiálunk a kérdés adatait:

- Kérdés neve: ide nem a tényleges kérdést kell felvinni, csupán egy címkét ami azonosítani fogja a listában
- Zászló: Ezzel logikai csoportokhoz társíthatjuk a kérdéseket. (A logikai csoportokat a FLAG tab alatt lehet beállítani)
- Csoport: A zászlóval ellentétbe a cimkében is megjelenő csoport névvel láthatjuk el a kérdéseket. Ilyenkor a kérdés címkéje a csoport nevével fog kezdődni, ami kapcsos zárójelben lesz látható.
- Nehézségi szint: Megadhatjuk, hogy saját érzésünk szerint az könnyű, közepes, vagy nehéz kategóriába esik.
- Kérdés: Maga a kérdés mezőbe írhatjuk a tényleges kérdésünket. Fontos, hogy formázási lehetőségünk is van.
- Csatolmány: Sajnos csak SVG képek csatolására van lehetőségünk egy kérdéshez, de ez is valami.
- Válasz: Kiválaszthatjuk, hogy egy vagy több helyes megoldás van-e a kérdésre, és persze a válaszokat is definiálhatjuk.
- Magyarázat. Lehetőségünk van magyarázat megadására is. Mi miért volt helyes illetve helytelen.

Az így felépített kérdések sajnos egy az egybe hosszú listát fognak alkotni. Lehetőségünk van szűrésre, de jobb lett volna valami skatulyázható fa szerkezet.

Server Mode

Amint megvannak a kérdések a szerverünket alkalmassá kell tenni arra, hogy vizsgázók/gyakorlók csatlakozhassanak hozzá.

A Server felületen is alapvetően három részre tagolódik a képernyő. Először is amennyiben bekapcsoljuk az advanced módot, akkor lehetőségünk van kérdések kiválogatására, amiből a vizsga álljon. Ezt látni a piros részen.

A sárga részen opcionálisan lehetőség van a pontozási rendszer meghatározására. Külön definiálhatjuk mennyi pontot érjen egy helyes, egy helytelen, és egy hiányzó válasz. Ezeket pedig szabadon variálhatjuk nehézségi szint szerint.

A zöld részen magát a teszt paramétereit állíthatjuk. Nevet adhatunk neki. Kiválaszthatjuk, hogy minden csoportból csak egy kérdést tegyen fel, megszabhatjuk a vizsgázó hány kérdést kapjon, illetve mennyi időt szánunk a válaszokra. Ezt akár kérdésenként is szabályozhatjuk. Külön állíthatjuk, hogy a teszt végén a vizsgázó mit láthassa-e a helyes válaszokat, illetve az eredményét, vagy a kérdés sorszámát.

Tetszőlegesen testre szabhatjuk melyik TCP porton halhasson a szerver majd indíthatjuk a servert. Amennyiben elindult minden funkció elérhetetlenné változik, és a szerverünk tényleges kiszolgálóvá válik.

Ilyenkor jöhetnek a kliensek.

Kliensek

Ahogy már mondottam a kliens alkalmazás teljesen független a szervertől. Elindítás után teljes képernyős ablak ugrik fel, amin a következőket fogjuk látni.

A kliensek esetében két lehetőségünk van. Vagy online mód csatlakozni egy serverhez. Ehhez meg kell adnunk az IP/host nevét és a portot.

A másik offline megoldásnál meg kell adnunk az adatbázis file helyét, és pár lehetőségünk van ezek után azon kapcsolók közül amit a server esetében láttunk. Én mindenképp a szerver-kliens használatát ajánlanám, később megmutatom miért. Nézzük mi történik, ha csatlakozunk a frissen létrehozott serverünkhöz.

Amennyiben a csatlakozás sikeres, akkor az ezen a serveren aktuálisan elindított teszt információit fogjuk megkapni.

Ha ezt elfogadjuk és elindítjuk, akkor a rendszer kérni fogja a nevünket.

(A server konfigurációjától függően) valami hasonló képet fogunk kapni.

Baloldalt látszódnak a kérdések címkéi, jobboltalt az aktuális kérdés maga (ha van a csatolmány is), lent pedig a válaszlehetőségek. Legalul azt is látjuk mennyi időnk van.

Amennyiben mindenre válaszoltunk, és a befejezésre kattintunk, befejezzük a vizsgát és attól függően, hogy konfiguráltuk a server megkaphatjuk az eredményeinket, és a kérdésenként azt, hogy mit rontottunk el.

Ilyenkor kiléphetünk a kliensből vagy új tesztet írhatunk. Viszont nézzünk vissza a szerverünkbe most.

Kimutatások értékelések

Server módban folyamatosan tudjuk realtime követni ki, és mit csinál, illetve lent egy rövid server log file-t is láthatunk pontos időpontokkal.

Természetesen a szerverünk ezeket az információkat tárolni fogja, és későbbi feldolgozásra is lehetőségünk van. Most fogjuk és kapcsoljuk ki a server, így visszakapjuk megint az uralmat a adminisztrátori felület felett.

A Saved Session alatt láthatjuk az összes próbálkozást, és megtekinthetjük ugyan azon adatokat, amit az előbb real time láthattunk. Ki, mikor, milyen válaszra, mit válaszolt, mi lett volna a helyes, stb.

Ennél érdekesebb viszont a Classes fül. Itt ugyanis csoportokat, és személyeket tudunk létrehozni. És vizsgákat személyekhez kötni. Ebből viszont már tendenciákat tudunk kimutatni. Ki milyen sokat vizsgázott, fejlődött-e vagy sem.

Ez most akkor könnyű vagy nehéz?

Sokszor előfordul, hogy a tesztet megíró egyén valamit könnyűnek nyilvánít, ami viszont nehéz. És sokan nem fogják tudni rá a választ. Az iTest mivel minden eredményt el tud raktározni ezért a kérdésekről is tud kiértékelést készíteni nem csak az egyénekről.

A database menü alatt, lehetőségünk van a kérdések kiértékelésére. A helyes-helytelen válaszok arányát tekintve az iTest pedig javaslatot tesz, annak minek kellene lenni. Így könnyen és egyszerűen alkalmazkodhatunk a szintekhez.

Összegzés

Az egyik legnagyszerűbb program amit erre a célra ki lehetett fejleszteni. Persze küzd néhány gyermekbetegséggel. Mint struktúrálatlan kérdések, server módban teljesen lekörlátoz minket, illetve egyszerre egy szerver nem tud több instance-t indítani.

Mégis ingyen van, használható, és nagyon intelligens. Természetesen minden fontosabb platformra.

A hivatalos weboldal megtalálható itt.

Előkészületek

A Solaris 10 alapból tartalmaz DNS server SMF service-t. Sajnos a konfigurációs állományok viszont teljes mértékben hiányoznak.

Ha megpróbáljuk bekapcsolni a következőt fogjuk tapasztalni:

# svcs dns/server
# svcadm enable svc:/network/dns/server:default
# svcs dns/server

# svcs -x
# tail -15 /var/svc/log/network-dns-server:default.log
# tail -15 /var/adm/messages

Jól látszik a syslog-ból, hogy nem találja a megfelelő konfigurációs állományokat. Ennek létrehozásához egy scriptet fogok én most használni, természetesen akinek van kedve, türelme, és tudja is mire, és hogy van szükség az megírogathatja kézzel is a BIND konfigját, és a zónák file-jait.

A script a HP ftp szerverén található meg ftp://ftp.hpl.hp.com/pub/h2n/h2n.tar.gz, vagy itt. Én ezt használom a továbbiakban.

Hosts file szerkesztése

A script az /etc/hosts file tartalmát fogja feldolgozni, és abból előállítja a megfelelő konfigurációs elemeket a DNS server számára. Fontos, hogy ezt a file-t a következő séma szerint hozzuk létre, különben a script nem fogja tudni feldolgozni.

# vi /etc/hosts

Script futtatása és a DNS konfigurációs állományok létrehozása

A szükséges scriptet én a /tmp-be töltöttem fel. Tömörítsük ki.

# cd /tmp
# ls -lah
# gunzip -c h2n-2.56.tar.gz | tar -xf -

A kitömörített könyvtárban a következőket láthatjuk:

# cd h2n-2.56
# ls -lah

Minden félét tudunk ellenőriztetni, illetve több formátumban is elérhető a hozzá tartozó dokumentáció. Nekünk viszont csak a h2n binárisra lesz szükségünk.

Másoljuk át innen a /etc folderbe.
# cp h2n /etc/
Most pedig jöhet a script futtatása és a szükséges állományok létrehozása. A következő szintaxist kell használni: h2n -d -n -u

# ./h2n -d test.oss -n 192.168.132 -u mihaly.paluska@it

A következő állományokat generálta ki a script:

db.cache beszerzése

Egy fontos file-t nem tud generálni a script. Ez pedig az az adatbázis file, amiből a DNS server a root zónákat keresné. Ezt szintén az internetről kell beszerezni (ftp.rs.internic.net).

Ezt a file-t a többi közé fel kell tenni a /etc folderbe.

Hálózati beállítások

Természetesen a rendszerünkön hiába fut egy DNS server, ha a gép nem akarja használni. Így most szépen beállítjuk a szükséges dolgokat. Egy kliens Solaris esetében is pontosan a következő három lépést / szerkesztést kell megejtenünk.

1, Adjuk hozzá a host feloldáshoz a DNS server opciót:
# vi /etc/nsswitch.conf

2, Adjuk meg az alapértelmezett domain-t amit használtunk a DNS server esetében is.
# vi /etc/defaultdomain
# domainname `cat /etc/defaultdomain`

3, Defináljuk a dns servereket és a dns suffixet.
# vi /etc/resolv.conf

Természetesen több nameserver bejegyzést is tehetünk ebbe a file-ba, ideális esetben kettő kell.

DNS Server SMF service indítása

Ha mindennel megvagyunk, akkor már nincs más mint elindítani a DNS SMF service-ket.

# svcadm enable dns/server
# svcadm enable dns/client

# tail /var/adm/messages

Teszt

Fogom és egy másik kliensen is végrehajtom a három szerkesztést amit fentebb a "Hálózati beállítások" résznél beírtam.

Ezek után nslookup-al mehet a teszt.

Végszó

Bízom benne hogy a fentebbi instrukciók alapján könnyen reprodukálható a beállítás. Természetesen, ha változtatni akarunk valamit a DNS serveren, csak a /etc/hosts file-t kell újra szerkesztenünk, és a h2n scriptet futtatni. Az előállítja a frissített konfigurációs állományokat, majd csak újra kell indítani a DNS SMF serviceket.

Előkészületek

Az NFS (Network File System) a SUN által kitalált adatmegosztó technológia. Erősen Linux/Unix alapokra támaszkodik, de Windows operációs rendszereken is elérhető. Az NFS egy server-client alapú technológia. Server oldalon egy az OS számára elérhető foldert kell kiválasztani, amiből egy "share"-t, megosztást kreálunk. Ezek után egy normál TCP/IP alapú hálózaton egy másik gépen a megfelelő NFS támogatással egyszerűen fel tudjuk mountolni ezt a file alapú tárterületet távolról. A megfelelő NFS támogatáson túl (ami manapság minden operációs rendszer alap tartozéka) csupán a hálózati kapcsolat szükséges a két IP között.

Solaris 10 esetében a következő SMF serviceknek kell hogy engedélyezve legyenek.

# svcadm enable nfs/server
# svcs nfs/server

Opcionális a következő, de ajánlott:
# svcadm enable nfs/client
# svcs nfs/client

ZFS tárterület felépítése

Én most nagyon a nulláról építkezem, ha valakinek már van egy zpoolja természetesen nem kell újat létrehoznia.

Én először szépen megnéztem milyen diskjeim vannak, és kiválasztottam kettőt:

# echo | format

Ezek után a két diskből építettem egy új Zpoolt:

# zpool create store c1t1d0 c1t2d0
# zpool status

Ezek után létrehoztam ezen a zpoolon belül egy új datastore-t, ami egyben majd egy NFS share is lesz:

# zfs create store/flash
# zfs list

NFS Share ZFS property által

Még mielőtt belekezdenénk nézzük meg alapból milyen property milyen értékkel látszik erről az új zfs datasetről:

# zfs get all store/flash

Kiemeltem azt a két részt amivel én a továbbiakban foglalkozni fogok. A quota az első, ami a maximális méretet hivatott szabályozni. A másik pedig a sharenfs értéke. Értelemszerűen itt tudjuk egyszerűen bekapcsolni, hogy ez a datastore NFS által meg legyen-e osztva.

A legegyszerűbb kapcsoló ha az sharenfs értékét "on"-ra állítjuk. Off értéken értelemszerűen ki van kapcsolva. Haladóbb szelleműek pedig értékként az nfs server által elfogadott beállításokat adhatunk meg. Lássuk én hogy tettem:

# zfs set qupta=20g store/flash
# zfs set sharenfs=rw,anon=0 store/flash

Ennyi. Kész. Ezzel csináltunk egy 20GB-os store/flash nevű nfs megosztást, amit bárki felmountolhat távolról írási-olvasási célra.

Teszt

# share

másik-host# mount 192.168.132.1:/store/flash /mnt
másik-host# df -h /mnt

Összegzés

Mint látszik, egyszerűen egyetlen zfs dataset változójával megoldhatjuk a megosztást. Ez pedig nem csak nfs-re igaz. Ha visszanézzük a listában elérhető a sharesmb, shareiscsi változó is. Ennél egyszerűbben tárhelyet és megosztást kezelni nehezebben lehetne. Csak ajánlani tudom.

Előkészületek

Először is a flash archive mint technológia már a Solaris 9-től kezdve elérhető alapértelmezetten. Így telepíteni nem kell külön.

Amiről gondoskodnunk kell, az egy tárterület amire a flash archive által generált archive állományt tárolni kívánjuk. Ez a tárterület egyaránt lehet NFS, CIFS, vagy csak egy mountolt szabad slice.

Az én esetemben:

Flash Archive készítése

Akkor nézzük, hogyan is lehet készíteni egy flash archive állományt. Fontos megjegyezni, hogy a folyamat teljesen aktív rendszeren alkalmazható, minden féle leállás nélkül. (Értelem szerűen olyan alkalmazás specifikus területeket, ahol folyamatos írás olvasás zajlik ott nincs garancia semmire a lementett adat konzisztenciájára)

# flarcreate -n archive1 -c -x /export/flash/ -X /etc/hosts -a OC2_SOLARIS -S /export/flash/archive1

Lássuk a használt illetve használható kapcsolókat mit rejtenek.

-n name of the archive file
-c compressed the archive file
-x exclude the affected directories (we have to exclude that file-system, which will contain the archive file to avoid the endless loop)
-X exclude file, (with the help of it, we can avoid the ip conflict on productive nodes)
-a name of the author
-S do not include sizing information
-I Set alternative creation date.
-y Include the named directory or file
-z Include files prefixed with a plus sign and exclude files prefixed with a minus sign in the file list.
-t Create an archive on a tape device.

Információ lekérése egy Flash Archive file-ról

Ha már kallódik sok flash archive file egy könyvtárban, akkor hasznos lehet ha ki tudunk nyerni információkat belőle. Erre való a következő kis parancs:

# flar -i archive1

Bár nem egy nagyon részletes leírást fogunk kapni, de legalább az kiderül, milyen rendszerről, és mikor csinálták. Jobb esetben az is, hogy ki.

Rendszer telepítése Flash Archive-ból

Az igazi haszna a Flash Archive-nak ott jön ki, amikor egy rendszert akarunk beállítani, ami totálisan megegyezik azzal, amiről maga a Flash Archive készült.

Lehetőségünk van fizikai gépet installálni vagy Zónát létrehozni Flash Archive állományból. Természetesen a gép neve, IP beállításai, és minden pre-configuration adat amit a telepítés igényel felül lesz írva a telepítő által, de minden más adat, script, alkalmazás ugyan az lesz.

Egy új gép telepítésénél a következő képernyőig kell elérnünk, ahol a Standard installáció helyett a Flash installációt kell választanunk.

Ezek után meg kell adnunk, hogy található az a Flash Archive file, amit fel akarunk használni. Lehetőségünk van távoli gépen elérni azt, vagy lokális médián.

Ebben az esetben én NFS share-t használtam, ahol pontosítani kell a PATH-t.

Az install összefoglaló képernyőn jól látszik, hogy Flash Archive van feltüntetve:

A telepítés a szokásos progress barral fog folytatódni, csak most a Flash Archive file tartalma lesz kitömörítve és lemásolva.

Zóna Telepítése Flash Archive-ból

Fizikai társához híven, ebben az esetben is magunknak kell gondoskodnunk a zóna config állományáról, viszont az install parancs esetében meg kell adnunk a flash archive-t mint forrás.

# zoneadm -Z ZONANEVE install -u -a /flasharchive/archive1

Összefoglalás

Tehát a Flash Archive egy jó megoldás arra, hogy rendszereket könnyen visszaállítható módon tudjunk archiválni, illetve klónozni. Gyors, egyszerű, és teljes támogatást élvez a Solaris egyéb részei által.

SAR installálása Solaris

Solaris alatt a SUNWaccu és SUNWaccr csomagoknak kell telepítve lennie. Ha ez nem lenne meg, akkor az install médián kell keresni.

Ezek után tudnunk kell, hogy a SAR mintavételezéssel dolgozik. Ezért a SAR mintavételezési scriptjeit a CRON-ba megfelelő képp időzítenünk kell. Íme egy ajánlott példa amit root-ként kell a crontabba rögzítenünk :

# Collect measurements at 10-minute intervals
0,10,20,30,40,50 * * * * /usr/lib/sa/sa1
# Create daily reports and purge old files
0 0 * * * /usr/lib/sa/sa2 -A

Az első bejegyzés a tényleges mintavételezésért felel, míg a második ezen adatok kiértékeléséért és a report "data file" létrehozásáért.

Simán a sar parancs segítségével kérhetünk szöveges kiértékelést a mérőpontok alapján.

# sar

A következő kapcsolók segítségével meghatározott mérési paraméterek adhatóak meg:

-a: Reports file system access statistics.
-A: Reports all data.
-c: System call reporter:
-d: Disk activity (actually, block device activity):
-e HH:MM: CPU useage up to time specified.
-f filename: Use filename as the source for the binary sar data.
-g: Paging activity (see "Paging" for more details):
-i sec: Set the data collection interval to i seconds.
-k: Kernel memory allocation:
-m: Message and semaphore activities.
-o filename: Saves output to filename.
-p: Paging activities.
-q: Run queue length and percentage of the time that the run queue is occupied.
-r: Unused memory pages and disk blocks.
-s time: Start looking at data from time onward.
-u: CPU utilization.
-v: Status of process, inode, file tables.
-w: System swapping and switching activity.
-y: TTY device activity.

(Linux esetében a sysstat csomag tartalmazza a SAR-t.)

KSAR és a grafikus kiértékelés

A sar parancs maga nem csinál mást, mint szövegesen feldolgozza a mérési pontok által összegyűlt adatokat és azokat hosszú sorokba és számokba foglalja. Ahogy fent jól látszik, rengeteg számot és flaget használva lehet csak teljesen átfogó elemzést adni egy gép aktivitásáról.

Ha valaki szép színes szagos diagrammos prezentációt szeretne belőle, akkor jön a copy-zgatás, és az exceles trükkök. Ez a halála az informatikusoknak.

Mint mindig most is van egyszerű és ingyenes megoldás. Ez pedig a KSAR. Ez java alpú, tehát minden java futtató környezettel (jre) rendelkező számítógépen futtatható. A kis grafikus tool alapvetően három feldolgozási módot ismer:

A KSAR minden esetben egy "sar -A" szöveges kimenetet vár, aminek kinyerésére három megoldást is kínál. Amennyiben offline formában, egy szöveges file-t kívánunk betölteni, úgy figyeljünk arra, hogy a következő parancs segítségével generáljuk azt ki, különben lehetnek feldolgozási problémái majd a KSAR-nak.

# LC_ALL=C /usr/bin/sar -A > /home/miszterx/sar`date '+%d'`

Értelemszerűen a létrehozandó file path-a tetszőleges lehet, a file nevére viszont érzékeny a KSAR.

Ezt ezek után felmásoljuk arra a gépre, amelyiken fel szeretnénk dolgozni, és betöltjük.

A második mód sokkal izgalmasabb, mert a KSAR képes arra, hogy amennyiben lehetőség van a direkt SSH kapcsolatra, akkor be SSH-zon, és a szükséges data file-t maga generálja ki. Tehát semmilyen parancs kiadása nem szükséges, csak megnyitni a saját gépünkön a KSAR-t, meghívni ezt a menüpontot, majd megadni azt, hogy milyen néven, és hova akarunk bejutni, majd a jelszót. Ezek után ha telepítve van a SAR és be is van időzítve, akkor automatikusan generálódni fognak az adatok.

A harmadik lehetőség pedig ha egy helyi parancs segítségével akarjuk előállítani ezen információkat. Ez akkor lehet érdekes ha a KSAR azon a gépen futtatjuk, amelyiket elemezni szeretnénk.

Ha valamelyik módon betöltöttük a megfelelő adatokat, és azt a KSAR fel is tudta dolgozni, akkor a következő képernyőt kell látnunk:

Ahogy láthatjuk az importálás sikeres volt, és minden féle adatot megtudunk ezek után arról, hogy milyen gépről, milyen időintervallumban áll rendelkezésünkre adat. Ezen túl a külön információ típusok a bal oldali menüben mint egyes menüpontok lesznek elérhetőek.

Ha bármelyiket kiválasztjuk, akkor a mérhető paraméterek által minden információ szép színes ábrákon fog megjelenni. Ha pontosítani akarjuk azt az intervallumot amit elemezni akarunk, akkor természetesen van rá lehetőség. Menjünk a DATA/Select time range menüpontba és a mérőpontok közül válasszuk ki melyikek közötti adatokra vagyunk csak kíváncsiak.

Exportálás

Most már csak az maradt hátra, hogy a management (vagy más hozzá nem értő ember számára) ezt kézzelfoghatóvá tegyük. A KSAR szöveges/táblázatos exportálást, a különböző diagramok egyesével történő mentését, és az egész reportot egy PDF-be mentését is támogatja.

Itt megtekinthető egy példa pdf az én tesztemről.

Végszó

A sar és a ksar együtt egy nagyon nagy segítség tud lenni minden Linux/Unix platform üzemeltetője számára. Mindkét program ingyenes, és használatuk pofon egyszerű.

Íme a támogatott platformok:

• Solaris 8, 9 and 10 (SAR és ESAR)
• Mac OS/X 10.4+
• Linux (Systat Version >= 5.0.5)
• AIX (4.3 & 5.3)
• HPUX 11.00+

A KSAR hivatalos oldala, rengeteg példával, fórummal, és minden nyalánksággal elérhető itt.

Felkészülés

Simulator telepítő: Netapp-7.1-sim-cdrom-image-v19.iso (96.6MB)
Rendszer: Ubuntu 10.04

Én egy VMWare masinán fogom szemléltetni a dolgokat, de természetesen egy fizikai rendszeren is ugyan így kell működnie mindennek.

Telepítés

Mountoljuk az iso-t.
# mount -t iso9660 /dev/cdrom /cdrom
# ls -lah

Indítsuk el a telepítőt.
# cd /cdrom
# ./setup.sh

Ezek után elindul a telepítő és interaktív módon válaszolnunk kell a feltett kérdésekre.

1. Hova installálja a simulátort? Válasz /sim ez a default.
2. Clustert installáljon-e? A mostani beszámolóban nem fogunk clustert installálni.
3. A HTML/PDF dokumentáció is legyen installálva? Igen hasznos lehet.
4. Folytatódjon az installációval? Válasszuk a yes-t.

Ekkor kitömörítődik a simulátor, és pár lényeges konfigurációs paramétert kell megadnunk:

5. Használunk DHCP-t az első induláshoz? Ha van és akarjuk használni yes, de nálam nincs ezért no.
6. Kérjel floppy-t a bootoláshoz? No.
7. Ki kell választatnuk melyik network interface legyen használva a simulátor által, az én esetemben csak egy van, úgyhogy maradhat default, amúgy azt kell beírni amelyiket használni kívánjuk.
8. Mennyi memóriát adunk a simulátornak? Default alap esetben elegendő lesz a funkcionális tesztekhez.
9. Csináljon-e minden session-höz új log file-t? Felesleges a mi esetünkben.
10. Felülírja e az egyszerű log file-kat? Had írja csak.

11. A simulátor 3 disket tartalmaz az a kérdés hányat akarunk még hozzáadni? Adjunk hozzá még hármat.
12. A következő disk méretekből kell kiválasztani melyiket szeretnénk használni. Én a legkisebbet az a-t favorizáltam most.
13. Disk adapter amire a diskeket rakhatjuk? Nulla.

A telepítés ezáltal befejeződött a kért diskeket legenerálta a szimulátor, és indíthatjuk is.

Első indítás

# cd /sim
# ./runsim.sh

Amennyiben a következő hibaüzenetet kapnánk nem kell megijedni:

runsim.sh script version Script version 19 (24/Nov/2005)
This session is logged in /sim/session/log
./runsim.sh line12 ./maytag.L: no such file or directory

Ez csak annyit tesz, hogy 64-bites a rendszerünk, a Simulator viszont 32-bites ezért fel kell tenni egy 32 bites csomagot ahhoz hogy fusson. Debian alapú rendszereknél ez:

# apt-get install ia32-libs

Ezek után már gond nélkül fog futni a NetApp simulator:

# cd /sim/
# ./runsim.sh

Első indítás és konfiguráció

Tehát itt járunk:

# cd /sim/
# ./runsim.sh

Az első indításnál alap konfigurációs kérdésekre kell válaszolnunk.

Adjuk meg a filer hostnevét. filer1.
Akarunk-e konkfigurálni virtuális hálózati interface-t a szimulátornak? Nem.
Adjuk meg az ns0 interface IP-jét. 10.0.0.100
Az ns0 interface netmaskja: 255.255.255.0
Adjuk meg az ns1 interface IP-jét: Ha nem akarunk többet megadni üssünk simán entert.

Ezek után kérdez rá a simulátor, hogy akarjuk-e a webes interface-n folytatni? Én most nemet választok, hogy kicsit jobban lehessen ismerkedni a simulátorral és a netapp környezetével. A webes környezetben is a további kérdésekre adott válaszokat kellene megadnunk.

Adjuk meg a default gatrway IP-jét: 10.0.0.2
Adjuk meg az adminisztráló host IP-jét, vagy hostját: 10.0.0.1 ez jelen esetben az én gépem.
Időzóna: GMT
Hol található a filer? Test system. Ez ilyen description mező féle
Milyen nyelvet használjon multi-protocol-os file-k esetén? Enterrel kihagyhatjuk ennek definiálását.
Akarunk DNS névfeloldást beállítani? Igen
Adjuk meg a DNS domain nevet: netapp.local
Ezek után definiálhatunk maximum három DNS servert: 10.0.0.2
Akarunk-e több DNS servert definiálni? Nem.
Akarunk-e NIS client-et futtatni? Nem.

Aktiváljuk az alapértelmezett root felhasználót, ehhez adjuk meg a jelszavát:

Akarjuk-e hogy a gép látható legyen WINS által? Nem.
Multiprotokolos vagy csak NTFS filer-t akarunk? 1 azaz multiprotokolost.
Adjuk meg a CIFS számára a root felhasználó jelszavát.
Alapértelmezetten a hostneve a gépnek lesz a CIFS server neve, meg akarjuk változtatni? Nem.
Active Directory vagy Windows NT 4 vagy Windows Workgroup vagy sima /etc/passwd file felhasználó kezelést akarunk használni? 4 mivel nekem egyik sincs.
Mi legyen a Workgroup neve? WORKGROUP

Ezek után minden beállítással végeznünk kell, amit az fog jelezni, hogy jelszó megadása után bejelentkezhetünk a filer shelljébe.

Netapp Filer management

Ezek után természetesen már egy futó és bekonfigurált NetApp filer webes management felületét érhetjük el a megadott hálózati címen.

Ha szeretnénk újra beállítani a rendszer paramétereket adjuk ki a következő parancsot:
filer1> setup
Amennyiben csak a CIFS beállításokat akarjuk újradefiniálni akkor előszór semmisítsük meg a meglévőket, majd újra indítsuk el a CIFS "varázsló" dialógust.

filer1> cifs terminate
filer1> cifs setup

Az install ezáltal be is fejeződött. A filer innentől fogva produktívan munkára fogható. Amennyiben ki akarjuk kapcsolni a simulator-t, akkor azt így tehetjük meg:

filer1> halt

Migrácó utáni hiba

Vegyük először azt az esetet, amikor kapunk egy ZFS exportot és egy zóna configot, amit be tudunk importálni (ezek a Solaris Zóna cikkben le vannak írva ezért nem részletezném). A zóna elindítása után bár elkezd bootolni, de a következő hibával szépen el is szál:

[root@ril-con19:/]# svcs -x
svc:/system/filesystem/local:default (local file system mounts)
State: maintenance since Thu Jun 10 16:49:35 2010
Reason: Start method exited with $SMF_EXIT_ERR_FATAL.
See: http://sun.com/msg/SMF-8000-KS
See: /var/svc/log/system-filesystem-local:default.log
Impact: 22 dependent services are not running. (Use -v for list.)

Amennyiben megnézzük a service log file-ját a következőt fogjuk tapasztalni:

[root@ril-con19:/]# [root@ril-con19:/]# cat /var/svc/log/system-filesystem-local:default.log
[ May 5 15:24:32 Method "start" exited with status 0 ]
[ Jun 10 16:43:44 Enabled. ]
[ Jun 10 16:43:47 Executing start method ("/lib/svc/method/fs-local") ]
Killed
WARNING: /usr/sbin/zfs mount -a failed: exit status 137
[ Jun 10 16:43:47 Method "start" exited with status 95 ]
[ Jun 10 16:49:34 Leaving maintenance because clear requested. ]

Ez jól szmbolizálja azt, hogy egy zóna, hogyha a nem megfelelő patch szinten van, illetve a system library ennyire elüt a global zónától, és még vannak közös (read only területek, amiket a global zónától örököl) akkor szinte biztos hibába fog futni.

Global zóna patchelése lokális (vagy cluster) zónákkal hiba

Azon gépek patchelése ahol zónák futnak, vagy ne adj Isten cluster kezeli a zónákat sokszor problémába futnak. Ekkor az szokott lenni a biztos megoldás, hogy a zónákat detach-eljük, sőt még a zónák tárterületéért felelős mountpointot is eltávolítjuk. Majd első körben a Global Zónát patcheljük meg. Ez általában megy is gond nélkül.

A probléma ilyenkor ugyan úgy fent fog állni mint a fenti migráció esetén, a lokális (vagy cluster) zónák patch szintje el fog ütni a Global Zónáétól.

Megoldás: Zones Update on Attach Feature and Patching

Ez a funkció a Solaris 10 5/08-től érhető el. A hivatalos túlspecifikált leírás itt. olvasható erről az új feature-ről. Én megpróbálom röviden és praktikusan összefoglalni azt, hogy a fenti két problémát hogyan tudjuk megoldani.

A kulcs a zonadm -z ZONENAME attach parancs lesz. Ez természetesen azt jelenti, hogy bár a zónának elérhetőnek kell lennie, de detach állapotba kell kerülnie. Ha attacholtuk már, nem kell megijedni, nem vesztettünk semmit, bármikor attacholhatjuk később is.

A mágia az attach-ben van, ahogy mondtam. Amennyiben így attacholjuk vissza a zónát, abban az esetben a Global Zóna megnézi az eltéréseket, és az attacholás előtt eltávolítja a nem kívánatos állományokat, és minden szükségeset installál, hogy újra szinkronba álljanak a patch szintek a global és a local zóna esetében.

# zonadm -z ril.con19 detach
# zonadm -z ril.con19 attach -u

Jól látszik, hogy a parancs után elindult a removing majd az install rész, végül pedig kaptunk egy uptodate zónát, amit kedvünkre indíthattunk is el.

Amennyiben van olyan patch, amit mi blokkolni szeretnénk azt explicit mód pluszban megadhatunk a következő módon:

# zoneadm -z my-zone attach -u -b 123456-08

Illetve, hogy ha azt akarjuk, hogy minden ajánlás ellenére se történjen semmilyen változtatás, akkor a következő parancsot kell használni.

# zoneadm -z my-zone attach -F

Az én konkrét példámban egy StorEdge 3320-as fog szerepelni. A következő paraméterekkel bír ez a doboz:

- Rack kivitel (1U magas)
- 512 MB belső memória
- 12 disk hely (Hot Swap)
- Ultra 160 SCSI / 15.000rpm diskek
- JBOD

A storage csatlakoztatása után ismertessük fel a diskeket:

# devfsadm -v

Jól látszik itt is, hogy van egy SES processor ami ahhoz a storagehez tartozik. Ez fontos lesz a jövőben.

# cfgadm -alv

Management Package telepítése

Nekünk a Sun Storage[TM] Configuration Service (SUNWsscs) csomagra lesz szükségünk. Ehhez sajna authorizált felhasználónak kell lennünk a SUN-nál. Létezik Linux, Windows, és Solaris csomag is a legújabb 2.5-ös csomaghoz. Lásd itt.

Ha ez megvan akkor a következő csomagot kell eljuttatni a storagehoz kapcsolódó Solaris masinára:

# cd /tmp
# ls -lah

Rakjuk fel a csomagot:

# pkgadd -d 2.5_fw_solaris_sparc.pkg

A sikeres telepítés után indítsuk el a konfigurációs agent deamon-t:

# /etc/init.d/ssagent enable start

Fontos megjegyezni, hogy a diskek enélkül a management tool nélkül is látszódnak és kezelhetőek.

Storage Box management

A telepítés után a következő dolgok lesznek elérhetőek:

- Sun StorEdge Configuration Service agent
- Sun StorEdge Configuration Service console
- Sun StorEdge Diagnostic Reporter agent (daemon)
- Sun StorEdge Diagnostic Reporter Config Tool (UI)
- Sun StorEdge Command-Line Interface (CLI)

Az utolsó a command-line interface (CLI)-vel fogunk a továbbiakban foglalkozni részletesebben. Ez az a tool ami által teljes parancssoros hozzáférést kapunk a storage-hoz.

# /usr/sbin/sccli

Amennyiben több különböző storage box is csatlakozik a gépünkhöz, abban az esetben eldönthetjük melyikhez kívánunk kapcsolódni. A mostani esetben csak ez az egy storage van, tehát egyből be is léptünk az Storage CLI-be, látszik, mert a promt is megváltozott. Innentől a CLI parancsai érvényesek.

Akkor most nézzünk pár fontosabb parancsot:

(Sajnos az én storage-m, egy sima JBOD encouser. Így a legtöbb parancs nem lesz támogatva ezeket be se mutatom)

sccli> version

sccli> show configuration

sccli> show enclosure-status

sccli> set led slot 10 on

sccli> show frus

Összegzés

Természetesen egy JBOD storage esetében elég kevés lehetőségünk adódik a storage állítgatásánál. Mégis külön management LAN nélkül egyszerűen tudunk információkat kinyerni a disk tárunkból, és szükség esetén kapcsolgatni ledeket. Amennyiben olyan dobozt kapnánk, ahol RAID támogatás is lenne sokkal több parancs és konfigurációs lehetőség lenne adott.

Az Sun Storage CLI teljes hivatalos dokumentációját elérhetővé tettem itt.

Az alap játék menet az az, hogy kattingassunk. Ide oda vigyük a kis robotunkat, ott megfelelő tárgyakat használjunk és lépésről lépésre tovább és tovább menjünk egyik szintről a másikba. Minden szinten valami újat fogunk megtudni a kis robot múltjáról, és arról hogy mit is kell tennünk.

Később annyival lesz nehezebb a dolgunk, hogy pályák között nem csak előre kell mennünk, hanem sokszor vissza fele is, igazi kis bolyongás. Természetesen ha elakadtunk sincs nagy gond, minden pályához részletes step by step segítség kérhető le, amennyiben a jobb felső kis könyvecskére kattintunk. Egy mini játékot kell végigjátszanunk érte, hogy kinyissuk a könyvet, de azután már minden információ a rendelkezésünkre fog állni az adott szintről.

Ami nagyon mellette szól, hogy nincs párbeszéd, csak kis rajzok és animációk, ami egyértelmű minden féle népcsoport számára. Elég hosszú játékról van szó, ami hosszú történetet mesél el, így jól le tudja foglalni az egész családot.

Ami másik szempontból nagyon pozitív, hogy minden féle operációs rendszerre (Mac Os X, Windows, Linux) elérhető ez a kis játék, lévén flash alapú.

Az első két pálya ingyenesen kipróbálható a hivatalos oldalon, és körülbelül 5000HuF ért megvásárolható a teljes játék.

HTML 5

Én elsők között említem a HTML5-öt, mert az Adobe (Flash) elleni harcban ez az Apple vesszőparipája, amivel az új utat akarja mutatni. Persze a HTML5 sem elfogadott standard még, így ez csak olyan "draft" HTML5 támogatást jelent.

Ami biztos az almás cég teljes mértékben e mellett a szabvány mellett szánta el magát. A HTML5-el lehetősége nyílik a fejlesztőknek video, audio anyagokat, minden féle pluginra támaszkodás nélkül is elérhetővé tenni a nagyközönség számára. Ezen túl viszont rengeteg csili-vili utópisztikus effekt is megoldható e szabvány által.

Az Apple, hogy bemutassa mennyire jó is ez, létrehozott egy demo oldalt, ami sajnos csak Safari-val tekinthető meg, itt.

DNS prefetching

Egy oldalon rengeteg link lehet, amely más oldalakra vezet. Ez a funkció annyiban kívánja meggyorsítani a böngészési élményt, hogy előre lekéri az oldalon található linkeket és előre összegyűjti a hostokhoz tartozó IP címet. Ezzel is nyerünk pár századmásodpercet, de miért is ne nyernénk ha nem kerül nekünk semibe, hisz a software előre dolgozik nekünk. Mi ebből semmit sem veszünk észre.

Nitro

Ez egy új Javascript motor. Mivel manapság minden oldal tele van szebbnél szebb, izgő mozgó dologgal ezért fontos, hogy ezek mögötti javascript kódokat milyen gyorsan tudja és persze mennyi erőforrás felhasználásával a böngészőnk feldolgozni. A Nitró érezhetően jobb, százalékosan 30%-al gyorsabb mint elődje.

Keresés az URL mezőben

Eddig is létező feature volt, hogyha valamit írtunk az URL mezőben, akkor ha hasonló linket talált, azt megjelenítette nekünk és választhattunk. Ez a tudása mostmár kiterjed a weboldalak címére is. Csak írnunk kell a mezőben, és ha az előzmények között lesz valamivel egyező tartalom már dobja is nekünk a linket.

Új tabban megnyílás

Nem nagy dolog, de eddig borzasztóan zavaró volt ennek az opciónak a hiánya. Mostantól viszont be tudjuk állítani, hogy mindig új tabon nyíljanak meg az oldalak új ablak helyett.

Reader

A Safari5-től a böngésző automatikusan érzékeli ha egy cikket olvasunk, és ilyenkor az URL mezőben megjelenik egy "reader" gomb. Erre kattintva egy külön dokumentumba exportálja nekünk a tartalmat, ami innentől akár külön is lementhető. Nagyon hasznos dolog, és innentől nem kell a weboldalon bajlódni a mindenféle konverzióval, mert a böngésző automatikusan megcsinálja.

Extensions

Egy nagyon régóta várt dolog került bele a Safari 5-be, ez pedig a pluginek támogatása. Ezidáig kemény tökönszórással lehetett hozzápászítani minden féle addon-okat a böngészőhöz, amikkel aztán mindig csak a baj volt, mert a böngésző frissítését nem nagyon tudták elviselni.

Most viszont végre megnyitotta a kapukat az Apple, és hivatalos API-n keresztül bárki írhat plugin-eket. Sajnos kicsit experimental dolog ez a PLUGIN dolog, tudni kell, hogy lehet bekapcsolni. Menjünk a Safari Preferences-ébe, ott Advanced tab, és lent pipáljuk be az Show Develop menu in menu-bar opciót. Ezek után már a menü sorban ott lesz a Develop menü is, amiben bekapcsolható az Extension kezelés.

Az Extension-okat a Preferencesben a Firefoxhoz hasonlóképpen tudjuk kezelni ezek után. A safariextz kiterjesztésű file-k ezek után dupla kattintással automatikusan betöltődnek a Safariba.

Összegzés

Alapvetően nagyon meg vagyok elégedve, gyorsabb, szebb és okosabb böngészőt kaptam. Persze olyan apróságokról nem beszéltem, hogy most már a Microsoft BING keresője is választható, mint alapértelmezett kereső a Safari számára, vagy hogy hardveres gyorsítást ígérnek Windows alatt a videó lejátszáshoz. Mindenképp megéri váltani, ingyen van.

Az Explorer először mint egy kis script indult el, majd annyira népszerűvé vállt, hogy sorra bűvölt a begyűjtendő információk számossága. Az tool több állomány tartalmát egy az egybe lemásolja, így az etc konfigurációs állományokat, és fontos log file-kat. Ezen felül viszont ő maga futtat parancsokat, és eltárolja ezen utasítások kimenetelit.

Az így létrejött információkat külön-külön sima szöveges állományokba tárolja le. Hihetetlen mennyiségű információról és így file számról beszélünk, amit szerencsére az Explorer már már megfelelő folder struktúrában tárol el.

A könnyebb hordozhatóság végett az Explorer kimenetele létrejön tömörített állományként is. Ezt az állományt kell elküldeni, vagy ezen adatokat felhasználni analizálásra.

A teljes Sun Solaris Explorer referencia dokumentuma, ami többek között tartalmazza minden egyes kimenet származtatását, és a program használatai lehetőségeit elérhető itt.

DOCUNIX: Automated System Documentation tool for your Sun Solaris System

Ez az Explorer szép dolog, mint mondtam, szinte minden lényeges adatot eltárol a gépünk akkori állapotáról. Többet mint amit egy ember manuálisan belátható időn belül fel tudna dolgozni. Ezen túl hasznos lehet az is, ha rendszeres időközönként generáltatunk a rendszereinkről Explorer-t és azokat centralizáltan tároljuk el.

Ez már csak azért is hasznos lehet, mert a SUN/Oracle a HW supportot nemrégiben attól tette függővé, hogy legalább egy Explorer outputot kell prezentálni három hónapos időközönként. Nem kell megijedni, ez természetesen nagy cégekre, és support-ra vonatkozik, ha valaki otthonra vesz két gépet, ott nincs ilyen megkötés.

Tehát az igény adott, gyűjtsük egy adott helyre időközönként az Explorereket, és dolgoztassuk fel, valami ember által könnyen értelmezhető módon.

Ebben nyújthat segítséget a DOCUNUX project. Elérhető itt, ingyenesen.

A program alapvetően három funkciót lát el:
- Alkalmazás csomag: Ez felel a feldolgozott információk megjelenítéséért a webes környezetben
- Core csomag: Ez a magja az explorer feldolgozásának és az adatok webes környezének
- Gyűjtő csomag: Ez segít az autómatizált Explorer begyűjtéséért.

Sajnos nem tudtam rájönni hogy az utolsó release mikori, de az biztos hogy aktuális verzió az a Docunix 2.0-3. Hivatalosan Solaris-ra és RedHar, Fedora platformokra létezik a csomag.

Én egy Ubuntu 10.04-re toltam fel a docunix-source-2.1.tar.gz SOURCE megjelölésű csomagot. Ez gyakorlatilag egy HTML interface ami PERL scriptekkel dolgozik.

Ezt a struktúrát tartalmazza az archív állomány:

/var/apache2/htdocs/docunix/
/var/www/docunix/
/var/docunix/

Ezek után a következő rewrite rule-kat kell még beállítani:

ScriptAlias /bin/ "/var/www/docunix/bin/"
ScriptAlias /sbin/ "/var/www/docunix/sbin/"

Az images könyvtárat néha érdekes helyeken keresi, arra én symlinkeket gyártottam, de alap funkcionalitás elérhető ilyen egyszerűen.

Ha üzemel, akkor menjünk a CONFIG menüpontba és adjunk hozzá egy új csoportot:

Ez gyakorlatilag a /var/docunix/etc könyvtárban fog létrehozni egy config file-t, amibe bekerül a csoport neve, és a folder ahol annak a csoportnak az explorerit találnia kell a perl scripteknek.

Ezek után ha ott vannak az archív explorerek akkor vmi hasonlót kell látnunk a HOME oldalon.

Jól látszik, ahogy listázódnak a gépek host nevei, a legfrissebb elérhető explorer dátuma, és az hogy ARCHIVE. Ez azt jelzi, hogy csak tömörítve van jelen, amennyiben többet akarunk tudni a VIEW likre kell kattintatunk. Először egy kis időt vesz igénybe, mert a rendszernek ki kell tömörítenie az archiv file-t. Ezek után már a HOME oldalon is így fognak a kibontott Explorerrel rendelkező hostok látszani:

Jól látszik, hogy már megjelenik a listában az OS és a kernel verziója ls a HW típusa. Persze az igazán hasznos dolgok akkor jönnek ha egyik hostba belekattintunk:

1. rész: Rövid HW összegzés a gépről
2. Kép a gépről (ez már saját HACK bele, az alap DOCUNIX nem tudja)
3. További és részletes adatelemzések a hostról.
4. Ehhez a hosthoz elérhető explorerek száma

A hármas pontot boncolgassuk még egy kicsit:

Explorer Shell

Viccesen hangzik, de többé kevésbé igaz, emulál nekünk egy shell-t az adott gépre. Mint ahogy írtam az Explorer rengeteg információt, és parancs kimenetelét tartalmazza. Amennyiben az Explorer Shell kis mezőjébe írogatunk parancsokat az Explorer a legjobb tudása szerint megjeleníti az eredményét. Elég jól működik.

View Files

Ez gyakorlatilag egy webes interface-t ad a file-ok böngészéséhez. Hogyha manuálisan dolgoznánk fel, gyakorlatilag ezt megjelenést kellene használni. Minden esetre ez is rendelkezésünkre áll.

Cron

Gyakorlatilag teljesen testreszabható keresést tudunk beállítani arra, hogy milyen időben, melyik user által milyen periódikusan lefutó cron parancsok voltak/vannak. Hasznos lehet ha egy régi időpillanatban kell nyomozni azt, hogy mi is okozott valamit.

Networking

Hálózati szekció. Szinte mindent megmutat a hálózati beállításokról. Érdemes itt már a fenti menüt is használni. Lekérhetjük az interfacek konfigurációját, routingot és névfeloldási beállításokat.

Patches and Packages

Amennyiben a /var/docunix/etc file-ba beletesszük a SUN-tól letölthető patch.xref referencia file-t (sunsolve.sun.com/patchdiag.xref), akkor a web frontend meg tudja jeleníteni nekünk a meglévő és hiányzó patcheket is elég informatívan.

Bármelyik diagramra rákattintva hozza a patcheket névvel számmal is:

Elég hasznos tud lenni.

Processes

Az Explorer időpillanatában futtatott processzorlista. Lehetőségünk van a sorrendet a mezők állapota szerint rendezni.

Storages

A tárolóegységekről is sokat megtudhatunk. Először is kapunk egy teljes átfogó képet arról, hogy milyen filerendszerek, milyen és mennyi diskünk van, és honnan tud bootolni a rendszerünk.

Ezen túl viszont egy fa struktúra szerűen ki is bonthatjuk a diskeket, filerendszereket ahol teljes kereszthivatkozások figyelhetőek meg, és nagyon informatívan láthatjuk mi mi alatt is helyezkedik el.

Collection Errors

Ez alatt a menüpont alatt gyűjti össze az oldal azon kimeneteleket, amik ERROR gyanusak. Ezek többnyire csak fals riasztások, mert az explorer minden lehetséges feature-t megpróbál letesztelni, amire gyakran az a válasz, hogy nincs, nem létezik, de érdemes ezeket mazsolázgatni ha tudjuk, hogy baj van.

Historical Comparison

Amennyiben létezik a hostunkhoz más-más időpontban készült, több Explorer is, akkor ez alatt a menüpont alatt lehetőségünk van azok összehasonlítására.

Reality Check

Itt a rendszer egy gyors valiadation testet futtat a fontosabb konfigurációs állományokon, és jelzi ha valami helytelenül lenne beállítva. Természetesen azt ki kijelzi, hogy szerinte hol van a gond, és többnyire azt is megmondja minek kellene helyette lenni.

Collection Administration

A rengeteg Explorer között lehetpségünk van bizonyos szabályrendszer felállítására. Megmondhatjuk, hogy automatikusan mennyi idő után archiválja le a rendszerünk a legutolsó/legfrissebb Explorert egy host esetében, mennyi idő után archiválja a nem legfrisebbeket, és mennyi idő után távolítsa el végleg azokat. Ezt mint globálisan, mint hostokhoz külön specifikálva is megadhatjuk

Show/Hide files used

Szinte minden menüpont esetében van egy "Show files used" kapcsoló a menüsorban. Amennyiben erre rákattintunk alul meg fog jelenni, hogy azon adatok kinyerésére mely file-ok voltak felhasználva az Explorerből.

Végszó

Az Sun Solaris Explorer egy nagyon jó találmány. Informatikai rendszerek támogatása esetén egy nagyon jó eszköz arra, hogy rendszerezni tudjuk a szükséges adatokat, és valamiféle standard féléhez igazodjunk. A Docunix pedig egy nagyon jó alap ha valaki ezt kötegelten, informatívan és automatizálva kívánja feldolgozni. Persze egyéni igények szerint tetszés szerint még testre szabható.

Bízom benne, hogy sikerült egy újabb okot adnom arra, miért jó Solaris rendszereket üzemelni.

Először nézzük mi hajtja ezt a csodát:

- 30 darab Apple LED Cinema Display 24".
- Mindegyik monitort egy-egy (tehát összesen 30 darab) Mac Pro hajtja meg.
- A rendszereket Mac Os X Snow Leopard vezérli
- A grafikai megjelenésért minden gépben egy EVGA NVIDIA GTX 285 grafikus kártya felel

Mit is kell látnunk?

Természetesen a 30 kijelző és az őket vezérlő rendszerek, mind mind össze vannak szinkronizálva, így közösen egy nagy kijelzőt alkotnak. A kijelzőn valós időben jelenítődnek meg (esnek fentről lefele) az Apple App Store-jából letöltött alkalmazások. Ezt egy XML feed által sikerült elérniük. Az adatok feldolgozását egy Objected-C alkalmazás teszi lehetővé (természetesen OpenCL támogatással) és a megfelelő renderelését a Mac Os X Quartz Composer-e.

Ha valakit lenyűgöz a technológiai szépségben és nagyságban, akkor ezt biztos szeretni fogja.

Persze a különböző tárgyakat kategóriákba is tudjuk csoportosítani, és ezáltal teljesen áttekinthetővé válik, hogy mi és mennyi dolog van a birtokunkban. Ezen felül hozzá tudjuk az kacatjainkhoz rendelni a használati útmutatót, és a garancia papírokat is.

Sajnos a program fizetős, 29$-t kell érte fizetni. A hivatalos oldal elérhető itt.

Tradicionális modell

Amennyiben valamilyen software raid1 megoldással rendelkezünk, akkor patchelés előtt szétbontjuk a tükröt, ellenőrizzük, hogy a második lábról is hiba esetén is fel tudunk el bootolni, majd az eredeti rendszerünket (első fele a tükörnek) megpatcheljük. Ha minden rendben örülünk és visszaszinkronizáljuk a root diskünket, hiba esetén pedig a másik lábról felállunk és oda szinkronizáljuk vissza az első tükör részt.

Szinte csak hátránya van, sok aprólékos állítgatás, hosszú szinkronizációs idők. Senki se szereti.

Live Upgrade

A tradicionális modellt figyelembe véve próbált erre a kérdésre megoldást találni illetve eszközt készíteni a SUN. Ennek a lehetőségnek lett Live Upgrade a neve.

Boot Environment

Először is fontos megismerkednünk pár új kifejezéssel. Az első ezek közül a boot environment (indulási környezet). Egy boot environment egy olyan "környezetet" fog reprezentálni, ahonnan a rendszerünk szeparát módon képes elindulni. Alap helyzetben nincs egy boot environment sem. Amikor egy újat akarunk létrehozni, akkor a rendszerünk elnevezi az aktuálisat egy névvel, majd egy új helyre átmásolja azt, ezzel létre hozva egy második, teljesen elszeparált részt. Természetesen akár hány boot environmentet létrehozhatunk.

Természetesen az új boot environment helyet is fog foglalni, ezért tudnunk kell, hogy azt eltárolni. Alapvetően három megoldás létezik:

1, Csak egyetlen root diskünik van.

Ebben az esetben találnunk kell egy üres slice-t, fel nem használt tárhellyel amit felhasználhatunk az új boot environment számára.

# lucreate -c solenv1 -m /:/dev/dsk/c0t0d0s3:ufs -n solenv2

2, Egy root diskünk van, de legalább az upgrade idejére tudunk betenni egy új üres disket.

Ebben az esetben az új disk valamelyik (vagy több) slice-jét tudjuk felhasználni az új boot environmentek tárolására.

# lucreate -c solenv1 -m /:/dev/dsk/c0t1d0s5:ufs -n solenv2

3, A root diskünk SVM tükörben van, a tükröt bontjuk és a megbontott tükör második lábát használjuk fel mint új boot environment.

Ebben az esetben azt az időt is meg tudjuk spórolni, amíg egyik helyről átmásolódna az adat a másik helyre. Ugyanis a tükör bontásával biztosra vehetjük, hogy teljesen konzisztens adatokat fogunk kapni. Így ez a leggyorsabb módja az előállításának.

# lucreate -n second_disk -m /:/dev/md/dsk/d20:ufs,mirror -m /:/dev/dsk/c0t1d0s0:detach,attach,preserve

Boot environment létrehozása filesystem bontással vagy egyesítéssel

Természetesen van lehetőségünk az új boot environment létrehozásakor a meglévő struktúrán változtatni. Ha teszem azt az /usr és /opt könyvtárak nincsenek külön filesystemeken, akkor ezt szétválaszthatjuk az új boot environmentek esetében, vagy ha külön vannka, akkor egyesíthetjük azokat.

Egy lemezes esetben:

# lucreate -c solenv1 -m /:/dev/dsk/c0t0d0s3:ufs -m /usr:/dev/dsk/c0t0d0s4:ufs -m /opt:/dev/dsk/c0t0d0s5:ufs -n solenv2

Több lemezes esetben:

# lucreate -c solenv1 -m /:/dev/dsk/c0t1d0s5:ufs -m /usr:/dev/dsk/c0t1d0s6:ufs -m /opt:/dev/dsk/c0t1d0s8:ufs -n solenv2

Egy lemezes esetben:

# lucreate -c solenv1 -m /:/dev/dsk/c0t0d0s5:ufs -n solenv2

Több lemezes esetben:

# lucreate -c solenv1 -m /:/dev/dsk/c0t1d0s0:ufs -n solenv2

Upgrade/Patching

Van tehát már két Boot Environment-ünk, Most már csak meg kellene patchelni/upgradelni az egyiket.

A live upgrade funkció Solaris8, Solaris9 és Solaris 10 alatt is támogatott. A következő csomagok szükségesek:

Ezek után egy viszonylag egyszerű paranccsal tudunk patchelni, upgradelni.

Telepítő CD/DVD-ről vagy imageről upgrade:

# luupgrade -u -n second_disk -s /cdrom/cdrom0
# luupgrade -u -n second_disk -s /net/installmachine/export/Solaris_10/OS_image

(Ha extra CD/DVD-ket akarunk megadni akkor ezt a szintaxist használjuk:

# luupgrade -i -n second_disk -s /cdrom/cdrom0 -O ’-nodisplay-noconsole’

)

Package-ket akarunk installálni a Boot Environment-be:
# luupgrade -P -n second_disk SUNWabc SUNWdef SUNWghi
# luupgrade -p -n second_disk -s /net/installmachine/export/packages SUNWijk SUNWlmn SUNWpkr

Patch-eket akarunk installálni a Boot Environment-be:

# luupgrade -T -n second_disk 222222-01
# luupgrade -t -n second_disk -s /net/installmachine/export/packages 333333-01 4444444-01

Boot Environment aktiválása

Amennyiben van már egynél több Boot Envinment-ünk, akkor érdemes lehet minden féle információt kinyerni belőlük, és persze igény szerint váltogatni a kettő között.

Aktuálisan felbootolt rendszer Boot Environment nevének lekérése:

# /usr/sbin/lucurr

Boot Environment átnevezése:

# lurename -e second_disk -n third_disk

Description hozzáadása egy Boot Environmenthez:

# /usr/sbin/ludesc -n second_disk ’Solaris 10 10/08 test build’

Boot Environment filerendszereinek részletes információi:

# lufslist -n BE_name

Boot Environmentek listázása:

# lustatus

Ha aktiválni akarunk egy másik Boot Environmentet, akkor pedig a kövekező egyszerű parancsot kell használnunk:

# /sbin/luactivate -s second_disk
# init 6

Ahogy látszik nem kell csodát várni, a luactivate se csinál mást mint a következő bootolást előkészíti, hogy a másik környezetről történjen. Tehát a Boot Environmentek közötti váltáshoz elengedhetetlen az újraindítás.

Persze, ha csak egy file-hoz szeretnénk hozzáférni a nem aktív környezetben, akkor lehetőségünk van mountolni azt az aktív rendszerünkben.

# lumount -n newbe /mnt

Sőt mi több, lehetőségünk van összehasonlítani a Boot Environmenteket.

# /usr/sbin/lucompare -i /etc/lu/compare/ -o /var/tmp/compare.out second_disk

Amennyiben pedig azt fedeztük fel, hogy egy ott kallódó boot environment túl régi, akkor törölhetjük is persze:

# ludelete second_disk

Összefoglalás

Így most sok-sok parancs és kitérést ejtettem, de hogy látszódjon mennyire egyszerű ezzel a lehetőséggel élni íme egy ábra a teljes folyamatról:

Live Upgrade ZFS alapú root zpool-al

Amibe én jobban szeretnék belemenni most, az a ZFS root pool alapú rendszerek Live Upgrade procedúrája. Ugyanis erre fele megy a világ, és a SUN/Oracle is ezt a vonalat nyomja ezerrel.

Íme az erdeti állapot, egy x86 Solaris 10 zfs rpoolal:

# zfs list

Akkor csináljunk egy új Boot Environmentet, és nézzük meg ZFS alatt mi fog történni.

# lucreate -c old -n new

Elemezzük egy kicsit ki mi is történt, méghozzá pillanatok alatt.

- A régi környezett old nevet kapott
- Az új new nevet kapott
- Egy snapshot jött létre az eredeti zfs filerendszerünkről
- Ez a snapshotból klónozódott egy új filerendszer new néven.
- Ez a klónozódott new filerendszer kapott egy noautomount flag-et, tehát nem fog csak úgy megjelenni automatikusan.
- A grub-ba is felvevődött az új környezet, tehát indulásnál most már választható lesz, hogy a new vagy az old Boot Environmentet akarjuk elindítani.

Most nézzük meg ez, hogy néz ki filesystem szempontból:

# zfs list

Melyik Boot Environment is aktív:
# lucurr

Nézzünk most egy státusz információt a Boot Environmentekről:

# lustatus

Jól látszik, hogy sorokba vannak gyűjtve a létező Boot Environmentek, oszlopokban pedig a sátusz információk. Láthatjuk, hogy teljes, befejezett Boot Environmentről beszélünk-e, azt hogy aktív-e most, hogy egy újraindítást követően aktív lesz-e, törölhető-e (csak nem aktív törölhető), és ha van neki akkor a másolási státuszát.

Ahogy már írtam most lehetőségünk van összehasonlítani a két Boot Environmentet:

# /usr/sbin/lucompare -i /etc/lu/compare/ -o /var/tmp/compare.out new

Lekérhetjük a filesystem információkat egy Boot Environment-ről:

# lufslist -n new
# lufslist -n old

Aktivájuk most a new nevű Boot Environmentet:

# luactivate -s new

# init 6

Bootolásnál a new névvel ellátott Boot Environment lesz az aktív:

# lucurr
# lustatus

Most lehetőségünk van a nem aktív (old) Boot Environment-et felmountolni:

# lumount -n old /mnt/
# df -h /mnt

Lemountolni értelemszerűen:

# luumount -n old

Ezek után törölhetjuk is akár a régit, amennyiben úgy érezzük, hogy nincs rá tovább szükség:

# ludelete -n old

Végszó

Remélem a fenti példákból jól látható milyen egyszerű módon kezelhetővé tette a SUN a Solaris rendszerek esetében a több környezet kezelését, és módosítását, és mennyi időt, erőt, és energiát lehet vele megspórolni.

A teljes hivatalos dokumentáció a Live Upgraderől elérhető itt.

Transzfer Ferihegyre, repülő Ferihegyről Berlinbe, majd vonat Berlinből Cottbusba. Ez volt a nem túl egyszerű terv, viszont nagy szerencsénkre egyik régi német kolléga felszedett minket Berlinben, és a vonat helyett háztól házig stílusban juthattunk el a céghez.

Ami először volt kicsit új émény az a rengeteg zöld erdőség az autópálya körül. Hihetetlen mennyiségben, szépen, rendben tartva magasodott körülöttünk a sok fa, már már monumentális méretekben. Majd másfél óra száguldozást követően megérkeztünk Cottbusba.

Hihetetlen sok időnk nem volt sajnos nézelődésre, szóval csak felületesek az élményeim, viszont nagyon meglepő volt ez a kis város. Kiterjedésben pontosan nem tudom mekkora, de alapvetően minden modern nagyobb városi épületet és jellegzetességet magán viselt. Nagy bevásárló központok, sok-sok emeletes irodaépületek, rengeteg busz és villamos vonal, hatalmas pályaudvar, egyetemi Campus. Ennek ellenére meglepően nem volt élet ebben a városban, az utcákon mindig járkáltak emberek, de nagyon messze volt az a tömegtől vagy forgalmi dugóktól. Lehet hogy már annyira megszoktam Magyarországon, hogy zavar ha ilyen nincs?

Ezek mellett Cottbus szíve az óvárosi rész volt, a mi szállónk is ide esett. Régi macskaköves utak, nagy terek, millió barok stílusú építmény. Persze nem kell azt gondolni, hogy a belváros maga a 1800-as évek. A tradicionális utcasorokon ott van a sok McDonalds, Burgerking, Nike, Adidas bolt. A németek valahogy megtalálták a régiben az újat.

Bár elméletileg a cég több telephellyel is rendelkezik, mi abba a szintén kicsit kiesnek tűnő épületben kaptunk helyet, ami a város szélén található. Kicsit meglepő volt, mert sok sok idősebb kollegára számítottam, viszont 20-30 közötti emberekkel találkoztunk csak.

Végezetül csak annyit, hogy Cottbus számomra maga volt az az idilli város, ahol nyugodt éveimet szívesen eltölteném. Minden minden annyira szép és békés volt. Az összes ott készült kép megtekinthető itt.

Először is nézzük a varázs parancsot, ami minden internetet elérő géppel működik függetlenül a platformtól:

nslookup -querytype=txt -domain=adventure - hastur.rlyeh.net

Ezek után a kacsacsőr promt utánmn egy "1"-t kell ütni majd entert. Ezek után a megjelenő szöveget értelmezni, és a megadott számokat beadva végigmenni a történeten.

A csel persze nem az nslookup-ban van, az csak teszi ami a dolga. A fenti szintaxis a hastur.rlyeh.net egy speciális domainja alatti TXT recordokat kéri le. Amikor mi "1"-est vagy akármilyen számot adunk be, akkor igazából abból a DNS serverből olvastatjuk ki a [SZÁM].adventure recordból a TXT (szöveges) bejegyzést. Ez a TXT record tartalmazza azt a szöveget amit az nslookup jelenít meg, mint kalandjáték.

Akárki más is csinálhat ilyet, aki saját DNS serverrel rendelkezik, és hasonló kép felépít egy TXT alapú record halmazt.

Ez is jól bizonyítja, hogy a zord technológia minden ágába lehet csempészni egy kis értelmetlen vidámságot, egy kis játék formájában.

The Rag Dolls

Ez a négy fős lány banda kezdte a sort. Sajnos nem tudom mióta zenélnek, és mióta létezik a csapat, de fiatal koruk ellenére nagyon tudták mitől döglik a légy. A két gitáros lány a kemény szikár stílusával a két oldalt, a babaarcú énekes hölgy a csodás fürtjeivel, a dobos lány pedig az igazi "durván élős" jellemével építi fel az együttest.

A csapat nagyon igyekezet kitenni magáért, többek között azért is, mert elkészítették első demó CD-jüket.

Rengeteg koncert videójuk megtalálható a YouTube-n, nekem mégis ez a kedvencem tőlük: The Rag Dolls playing This is how a heart breaks by Rob Thomas

Ezen túl a lányoknak van hivatalos weboldala is, itt.

Muzak Box

Szintén négy fős együttes követte a lány zenekart. Mondhatnám kicsit tipikus felépítésben. Egy merengő dobos, csendes igazi művésztípus gitárosok, és egy isteni hangú pici lány. Először nem is értettük, hogy a kis pöttöm kislány mit keres a színpadon, amíg a hihetetlen dögös hangjával nem kezdett el a mikrofonba csacsogni. Ámulatból csak bámulatba estünk, mert a zenészek nagyon értették a dolgukat. A dobos és basszusgitáros srácok egymást ostromolva nyomatták a jobbnál jobb szóló részeket, a gitáros srác a mellett, hogy szintén kiválóan zenélt, pedig hihetetlen vékony hangon tudott vokálozni.

Visszakanyarodnék még az énekeshez, Kovács Boglárkához, hisz azon túl hogy zeneileg fantasztikusat alakított, hihetetlen profizmussal kezelte a közönséget. Olyan hölgyről van szó, aki ha feltűnik akkor minden kicsit már körülötte forog. Isteni beszólásai vannak, jó konferálása, sőt mi több érzi a közönséget és teljes mértékben tudja motiválni őket. Az pedig, ahogy a színpadon él, hát le a kalappal.

Ő tőlük mindenképp szerettünk volna DEMO CD-t hozni. Fel is lett konferálva, hogy 500HuF áron lehet venni a koncert után. Neki is indultunk, de sajnos mire az ostromgyűrűn keresztül megközelíthettük volna a hölgyet, hallottam, hogy nincs több. Szomorúan elkezdtünk elsompolyogni, mire a Boglárka utánam futott, és hihetetlen kedvesen megkérdezte, hogy mi is szerettünk volna CD-t? Mire mondtuk, hogy hát persze... Elmondtam, hogy én egészen Debrecenből jöttem hogy halljam őket. Erre a világ végéről is előásott nekünk egy CD-t amin a számaik voltak. Őszinte köszönet érte neki. Még az 500Ft-ot is úgy kellett rá tukmálnom érte.

Mint kiderült a Muzak Box felfele tör, már készül az első videó klippjük. Addig is van nekik myspace oldaluk itt, meg facebook oldaluk itt. Ahol lehet követni mizujs velük, és aktuális számokat meghallgatni.

Összeségében hihetetlen élmény volt számomra. Nem is úgy fogalmaznék, hogy a nagyokhoz hasonló minőségi zene napja volt, mert én ezt nem tudom megítélni. Az biztos, hogy engem teljes mértékben szórakoztatott, és átütött a közeli színpadról, hogy ezek a csapatok szívből-lélekből zenélnek. Se nem megasztárok, se nem celebek, meg ilyenek. Ők zenészek.

Erre pedig most született egy ingyenes és egyszerű kis program. Ez a gfxCardStatus.

A program alapvetően lehetőséget ad arra, hogy manuálisan állíthassuk válthassunk az Intel® HD Graphics és az NVIDIA® GeForce GT 330M kártyák között. Ezen túl a menü bar-ra egy "i" vagy egy "n" jelzi automatikusan, melyik az kártya aktív. Amennyiben pedig átkapcsolás történik akkor a program Growl-os figyelmeztetést küld.

A kis tool ingyenesen elérhető itt

Tehát a program a kép alapú dokumentumunkból felismeri a szöveget, és automatikusan kereshető, kijelölhető szöveggé emeli ki a dokumentumunkban.

Nagyon egyszerű kis funkció, a megvalósítása persze annál nehezebb. Sajnos pont e miatt csak a következő nyelvek elérhetőek: Angol, Német, Francia, Holland, Olasz, Japán, Orosz, Kínai. Sajnos ahogy látszik a kis európai országokban nem éreztek a srácok piacot.

Ha valakit így is érdekelne akkor 39$-ért megvásárolható a hivatalos oldalon itt.

A jellegzetes kamion tehát újra robog. Nem is akár hogyan, hisz a jelentősen átgondolt szerkezet mellett grafikailag is megújult a program. Először is a kis dock ikon sokkal szebb és részletesebb kidolgozást kapott.

Másodsorban a két panelos kezelőfelület is új színekben és formákban pompázik. Azt kell hogy mondjam, hogy igazán Leopard design-t sikerült neki kölcsönözni. Dícsérendő a könyvtárak feletti struktúrázott path kijelzés, a sokkal jobb és szemléletesebb tab kezelés.

Ezen túl kifejezetten kihangsúlyozandó, hogy bár a Transmit 4-el érkezik, de nem képezi magának a kliensnek a szerves részét a menüben bekapcsolható Transmit menubar. Ez a Transmit 4 elindítása nélkül is működik természetesen, mert más process táplálja ezt a funkciót. Itt egy "gyors" indító menü érhető el gyakorlatilag. A kedvencek közé felvett accountokat hívhatjuk meg innen. Viszont új lehetőségként eme "storage" accountokat lehetőségünk van felmountolni automatikusan a rendszerünkbe, amit ezek után egyszerűen finder alól kezelhetünk. Legyen az FTP, WEBDAV, SFTP, akármi. Nagyon szép és hasznos lehetőség ez.

A szépségén, az új rendszerintegrációs komponenseken túl sebességben is javult az új verzió, tehát érdemes megvásárolni.Az ára 34$ a hivatalos oldal pedig megtekinthető itt.

A "történet" azzal kezdődik, hogy mutatnak egy kék színű kis gömböt, egy mini organizmust, amiről kiderül, hogy mi magunk vagyunk. Majd jönnek a kötelező betanító pályák. Először meg kell tanulnunk, hogy tudunk helyet változtatni. Az egér segítségével vezérelve tudunk az organizmusból kilökni pár kisebb részt, ezzel "meghajtást" generálva. Persze ilyenkor a kilövellő anyag a saját organizmusunk térfogatát csökkenti, ezért csak ésszel kell ezt a manőverezést is csinálni.

A játék automatikusan kékkel jelzi azokat a kisebb entitásokat, amikhez ha közel megyünk be tudunk kebeleznünk. Ilyenkor persze nő a saját gömbünk mérete, és ezért újabb más gömbök válnak bekebelezhetővé. Persze a piros színűektől ódzkodjunk, ezek nagyobbak mint mi, és ők tudnak bekebelezni minket.

Természetesen a sok-sok pályán minden féle új kihívás vár minket, de az alap célkitűzés mindig ugyan az. Légy Te a legnagyobb! Többnyire a pályák akkor érnek véget, ha a legnagyobb entitássá tudjuk magunkat kinőni. Néhány speciális helyzetben, pedig egy kijelölt organizmust kell bekebeleznünk.

A játék második nagyon szimpatikus jellegzetessége, hogy minden fontosabb desktop operációs rendszerre elérhető. Mac Os X, Windows, Linux. A demókat bárki letöltheti, viszont a teljes verzióért már fizetni kell csekély 10$-t.

Én mindenkinek csak ajánlani tudom. A hivatalos oldal elérhető itt.

A Csokonai étteremben foglaltunk egy asztalt, és természetesen minden Solaris adminisztrátor tiszteletét tette. Bár mint minden csoportban nálunk is voltak konfliktusok, és összetűzések, de jó volt látni együtt minket, hisz a széttolt munkarend, a készenlétek miatt erre nem sok lehetőség szokott leni.

Ági emlékül a mögöttünk álló időről kapott egy bögrét. A bögrére nem kevés erőfeszítés árán sikerült a bográcsozós egyik csoportképet rátetetni. Kicsit vicces, hogy azóta azért sokat változott a Solaris csoport személyileg, de úgy voltunk vele, nem feltétlenül az számít ki van rajta vagy ki nem, hanem az a pillanat.

A nagy evés ivás után gyakorlatilag zárásig duhajkodtunk. Utána a kemény mag gyakorlatilag Debrecent végigordítozva minden még nyitva tartó kocsmát meglátogatott.

Zárásként csak annyit, hogy sok sikert kívánunk Áginak a jövőben, és köszönjük a munkáját.

Az összes kép megtekinthető itt.

Előkészületek

Én Ubuntu 10.04-en fogom bemutatni a dolog működését, de amennyiben nincsenek alapból a dm-crypt szükséges csomagok telepítve, akkor a következő képen tehetjük meg.

# apt-get install cryptsetup

Illetve bizonyosodjunk meg, hogy a következő kernel modulok be vannak-e töltve:

# modprobe dm-mod
# modprobe dm-crypt
# modprobe aes

Disk titkosítása

Feltételezzük, hogy van egy felhasználható disken egy előkészítet LINUX partíció. Ez az én esetemben ezt a /dev/sdb1 fogja megtestesíteni. A következőkben inicializálni fogjuk a disket, létrehozva a megfelelő LUKS formátumú titkosítási struktúrát. Ezek után meg kell nyitnunk ezt a titkosított eszközt a megadott passphrase-el, majd ezzel egy időben a device mapper létre fogja hozni a diskünk és partíciónk megfelelő másolatát. Ez lesz amit használatba vehetünk. Tehát a következő történik:

Natúr disk partició [===] DM-CRPY titkosít [===] Device Mapper [===] Mountolható emulált device

Az ehhez a folyamathoz tartozó parancsok:

# cryptsetup luksFormat /dev/sdb1

Disk Megnyitása

Ezzel előkészítettük a disket, és a megfelelő kulcsal letitkosítottuk. Ezek után:

# cryptsetup luksOpen /dev/sdb1 titkositott

A fenti paranccsal pedig megnyitottuk olvasásra. Természetesen igazolnunk kellett a megfelelő passphrase-vel magunkat (Ugyan az amit a létrehozáskor megadtunk). Ezek után a parancs végén lévő néven a device mapper elérhetővé teszi az új már írható olvasható device-t. Ez az én esetemben /dev/mapper/titkositott. Mostmár rakhatunk rá filesystem-et, és mountolhatjuk.

# mkfs.ext3 /dev/mapper/titkositott
# mount /dev/mapper/titkositott /mnt/
# df -h /mnt/

Titkosított disk lecsatolása

Először is a filerendszert csatoljuk le.
# umount /mnt

Aztán a device mapperből csatoljuk le az device linket, amin keresztül eddig használtuk a letitkosított disket.

# cryptsetup luksClose titkositott

Több Passphrase megadása

Lehetőségünk van több passphrase megadására is és amennyiben több van törölhetünk is belőlük.
# cryptsetup luksAddKey /dev/sdb1

Illetve a törlés, ahol meg kell azt is adnunk hanya passphrase-t akarjuk törölni:
# cryptsetup luksDelKey /dev/sdb1 1

Ilyen egyszerű az egész.

Természetesen van lehetőség arra, hogy automatizáljuk valamennyire a dolgot. Az evidens, hogy az /etc/fstab-ba felvihetjük a device mapper device mountolását, viszont az csupán nem elég, hiszel először tuksOpen-el meg kell nyitni a titkosított diszket, hogy az mountolható lehessen. Ezért egy új config file-t, az /etc/crypttab kell felkészítenünk még pluszban.

DD-zés

A legalapvetőbb, és minden UNIX/Linux platformon elérhető kis parancs a DD. A DD nem csinál mást, mint a meghatározott inputról mindent bitről bitre átmásol az output-ra. Ami lehet file, device, akármi. Természetesen mindent felül fog írni, így ha nem tök üres, disk-el tesszük ezt akkor az adatvesztéshez fog vezetni!

A legegyszerűbb tehát fogni, és a /dev/urandom (véletlengenerátor) device-t megadni inputként, és onnan szépen írni az új diskünkre. Sajnos nem nagyon lehet semmi progress bar-t látni folyamat közben, csak várni kell.

# dd if=/dev/urandom of=/dev/sdb

Ahogy látszik a fentebbi képen, a DD idővel teleírta a disk tárterületét. Akkor szépen leállt. Az én esetemben 6.1MB/s sávszélességgel és közel 3 perc alatt végzett. Eközben nem volt hiba, tehát a disk használhatónak tűnik.

Badbocks

Kicsit intelligensebb, bár alapvetően a DD-hez hasonló funkciót valósít meg a badblocks. Hasonlóképpen írási próbát fog végezni a megadott disken, tehát minden előtte lévő adat el fog veszni. Erre figyeljünk oda.

# /sbin/badblocks -c 10240 -s -w -t random -v /dev/sdb

A "-c" után a tesztelésnél használt blokk méretet, a "-t" után a tesztelés típusát lehet megadni lehet megadni. A "-s" el bekapcsoljuk azt, hogy egy minimál progress bar-on mutassa nekünk hol jár, a "-w"-vel pedig adjuk meg neki, hogy írási teszt is legyen.

Ahogy látszik ez a badblocks kicsit intelligensebb és informatívabb.

Alap helyzet

Egy CDROM és egy DISK van a virtuális rendszernek adva:

Adjunk hozzá hot-swap egy új disket

Persze OS oldalról semmit nem fogunk még látni ebből. Legalábbis még.

Pásztázzuk újra a scsi csatolót

A következő paranccsal tehetjük ezt meg. Egy speciális stringet kell küldenönk a megfelelő sys devide-nek.
# echo "- - -" > /sys/class/scsi_host/host2/scan
# fdisk -l
# cat /proc/scsi/scsi

!! Fontos, hogy az scsi_host-on belül ha több host[SZÁM] device van, akkor a jóra alkalmazzuk.

A syslogban a következő nyoma lesz az új disk felismerésének.

Disk Eltávolítása a rendszerből

Természetesen alap az, hogy ha volt rajta filerendszer, akkor azt umountoljuk. Majd a következő paranccsal eltávolítjuk:

Egy disk explicit hozzáadása

Ha nem scannelni akarunk, hanem tudatosan egy bizonyos disket hozzáadni, akkor arra is van lehetőség:

# echo "scsi add-single-device [h] [b] [t] [l]" > /proc/scsi/scsi

* [h] : Host
* [b] : Bus (Channel)
* [t] : Target (Id)
* [l] : LUN numbers

A mostani konkrét esetben:

# echo "scsi add-single-device 2 0 1 0" > /proc/scsi/scsi

Élet az LVM nélkül

Alap helyzetben vannak a diskek. Azokat egyszer statikusan feltudjuk darabolni részekre (partíciókra), és azokra filesystem-et tehetünk. Ezeket tudjuk ész nélkül mountolni. A hátránya az, hogy egy Linux-os filesystem struktúrába is lehetőségünk van mountpointokat skatulyázni, viszont kényelmetlen lehet. Arról nem is beszélve milyen átláthatatlanná tud válni egy össze vissza skatulyázott rendszerstruktúra.

Mire jó az LVM?

Az LVM gyakorlatilag a fizikai diskek és a filesystem közötti új réteg. Feladat pedig az, hogy a fizikai statikus tárterületeket dinamikusan tudja szabályozni. Ezáltal a tárterületek egyszerűen, és több esetben leállás nélkül is újraszervezhetőek.

Előkészületek az LVM-hez

Én jelen esetben három új disket adtam hozzá Ubuntu 10.04-es rendszeremhez
# fdisk -l

Látszik, hogy tök üresek a diskek. Létre kell hozni rajta egy (vagy tetszés szerint több) partíciót aminek LVM típusúnak kell lennie. Én ezt az első disken bemutatom, de mindhármon meg kell tenni.

Fdiskel nyissuk meg az első disket:
# fdisk /dev/sdb
Az fdisk menüjébe üssünk egy "n" betűt, azaz új partíciót akarunk létrehozni.

Command (m for help): n

Meg fogja kérdezni, hogy extended vagy primary partíciót akarunk. Válasszuk most a "p"-t.
Meg kell adnunk melyik partíciót akarjuk létrehozni. Mivel nincs, válasszuk az egyest.

Partition number (1-4): 1

Hanyas cilincertől kezdődjön:

First cylinder (1-130, default 1): 1

Hanyas cilindernél érjen véget:

Last cylinder, +cylinders or +size{K,M,G} (1-130, default 130): 130

Már csak ki kell választanunk a partíció típusát:

Command (m for help): t

A "L" betűvel kérhetjük le a teljes listát, de nekünk Linux LVM kell, ami a "8e":

Hex code (type L to list codes): 8e

Már csak ki kell írnunk a diskre a változtatásokat:

Command (m for help): w

Ha készen vagyunk akkor hasonló kimentet kell látnunk:
# fdisk -l

LVM használata

Physical Volume

Először is ahogy már feljebb elhangzott három rétege van az LVM-nek. Az első a Physical Volume=pv (Fizikai Kötet). Persze nekünk már vannak diskjeink LVM partíció típussal, de ahhoz hogy ezekből pv-diskek legyenek, inicializálnunk is kell.

Ezt tudjuk megtenni a következő paranccsal:

# pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1

Ha ki akarjuk listázni az aktuális pv-ket, akkor azt a következő paranccsal:

# pvdisplay

Ha törölni szeretnénk (csak ésszel, és olyat amire biztos nincs szükség), akkor azt a következő módon tehetjük meg:

# pvremove /dev/sdb1 /dev/sdc1 /dev/sdd1
# pvdisplay

Volume Group

A Volume Group nem más, mint egy csoportosítás. Itt jelenik meg először a közös "pool" szemlélet. Egy zsák amibe bedobáljuk mindazt amink van, a nagy közösből tetszőleges méreteket különíthetünk el. Ha például akarunk csinálni egy kötetet a root filrendszernek, és az adatok tárolására egy másikat, akkor jobb két külön csoportba sorolni. Természetesen egy PV vagy LV csak egy Volume Grouphoz tartozhat egyszerre.

Csináljunk egy új groupot a most létrehozott diskeknek (ha nem lennének a megadott diskek PV-k, akkor ezzel a parancsal, azok is létrejönnek).

# vgcreate data /dev/sdb1 /dev/sdc1 /dev/sdd1

Most ellenőrizzük, milyen Volume Groupok léteznek, és azokról mit lehet megtudni.

# vgdisplay

Ahol látszik a csopornak van egy mérete, ez a VG Size. Ennyi a pool nagy felhasználható mérete. Alatta a PE az az egység amikre felosztódik a volume group. Az én esetemben látszik, hogy ez 4MB, tehát 4MB-os egységekre van felkockázva a zsák. A Total PE azt mutatja, hogyha 4MB-os egy kocka akkor a zsákban hány kocka van. Lejebb pedig PE és tárhelyre lebontva is láthatjuk mennyi már kiosztott (Allocated) vagy még nem kiosztott (Free).

Értelemszerűen törölhetünk is egy volume groupot ha akarunk.

# vgremove data

Amennyiben a rendszerünk számára elérhető diskeken már van valamilyen LVM, csupán a rendszerünk nem látja még, akkor a következő parancs nagy segítségünkre lehet.

# vgscan

Logical Volume

Az utolsó rész pedig a Logival Volume-k, azok a virtuális szeletek a pool-ból, a Volume Group-ból, amikre filesystem fog kerülni. Ez talán a legfontosabb rész, hiszen ezen szerkezeti egységekből lesznek virtuális device-k, amiken tárolni fogunk.

Először is nézzük, hogy tudunk létrehozni egy LV-t.

# lvcreate --name elso --size 100M data

Jól látszik, hogy a parancs után nevesítenünk kell az új LV-t, majd megadni mekkora legyen a mérete, végül pedig, hogy melyik VG-ből legyen kiajánlva a terület. A parancs után a flag-eket, természetesen rövidítve is meg lehet adni.

Ha csináltunk egy új LV-t a data VG-n belül, akkor a megszokott parancs konvenció szerint kilistázhatjuk az lvdisplay paranccsal. Viszont amennyiben több VG-nk van, és azon belül is több PV, akkor a teljes lista hihetetlen nagy tud lenni. Ezért a parancs után definiálhatjuk melyik VG-ben akarjuk látni az adatokat.

# lvdisplay data

Ha egyszerűsített formába szeretnénk látni, vagy bármely block device-n akarunk felismertetni elkóborolt LV-ket, akkor a következő parancs hasznos lehet.

# lvscan

Illetve a létrejött device alapaján is lekérhetjük. A LV device-t a /dev/[VG_NAME]/[LV_NAME] alatt találhatjuk.

# lvdisplay -v /dev/data/elso

Természetesen törölni hasonlóképpen tudunk egy LV-t.

# lvremove /dev/data/elso

Ezek után már csupán a megfelelő filesystem-et kell a volume-ra ráhúzni, és mountolható is.

# mkfs.ext3 /dev/data/elso
# mkdir /elso
# mount /dev/data/elso /elso
# df -h /elso/

Amennyiben permanensé kívánjuk ezen mountpointokat tenni, akkor természetesen szükség lesz az /etc/fstab szerkesztésére.

Gyakori karbantartási munkák LVM-el

Volume növelése

Gyakori kérés, hogy növeljük meg a volume/mountpoint méretét. Fontos, az LVM támogatja természetesen ezt a műveletet, de az LVM csak egy virtuális disket ad, fontos, hogy a rajta lévő filesystem is támogassa azt. Én most EXT3-mal fogok játszadozni, de természetesen más filesystemek is tudják ezen funkciókat.

Első lépésként meg kell növelnünk a kívánt LV méretét. Erre két lehetőségünk van, vagy megadhatjuk mennyivel növekedjen a meglévő méret, vagy kijelölhetjük az új méret határát. A mostani volume mérete 100MB. Ha 200MB-ra akarom növelni a következő két parancs valamelyikét használva:

Itt azt adjuk meg menyivel legyen nagyobb:
# lvextend -L+100M /dev/data/elso
Itt azt adjuk meg, mennyi legyen az új nagyobb mérete:
# lvextend -L200M /dev/data/elso

Természetesen ekkor még csak a LV mérete nőtt meg, a mountolt filesystem mérete az változatlan.
# df -h
# lvdisplay -v /dev/data/elso

Akkor most növeljük az új LV méretéhez a filesystem méretét is. Ezt természetesen legbiztonságosabban akkor tehetjük meg, ha a filerendszerünk nincs mountolva, de bizonyos filesystem-ek támogatják az online bővítést is.

# resize2fs /dev/data/elso
# df -h /elso/
# ls -lah /elso/

Természetesen online/mountolt állapotában fogja a filesystem-et növelni, és minden adatunk sértetlenül megtalálható lesz.

Volume csökkentése

Míg a növelés kicsivel egyszerűbb, a csökkentés nehezebb, hisz a filerendszerhez a végéhez üres területet hozzácsapni egyszerűbb, de ahhoz hogy csökkenteni lehessen, ahhoz először egybefüggővé kell tenni az adatokat (defragmentálni), hogy a végén a filerendszernek teljesen üres területet különíthessünk el. Ezt fogjuk ugye leválasztani.

Itt sajnos ajánlás szerint mindenképp umountolnunk kell.
# umount /elso/
Ezért először FSCK-t futtatunk rajta.
# e2fsck -f /dev/data/elso
Ezek után, hogy elvileg folytonos a filesystem jöhet a csökkentés. Én a példában 100MB-ra csökkentem vissza.
# resize2fs /dev/data/elso 100M
Hogy már a filesystem kisebb az LV-ot is kisebbre vehetjük. Természetesen figyelmezteni fog, hogy a csökkentés roncsolhatja a filerendszert, de mivel mi gondoskodtunk már róla, ezért nyugottan mondjunk neki Y-t.
# lvreduce -L100M /dev/data/elso
Ezt követően már a csökkentett méretű filesystem mountolható is.

Disk cseréje egy Volume Group-ban
A helyzet a következő, kinőttük a meglévő disk csoportunkat. Alap esetben persze amíg lehet bővíthetünk, a most következő téma azt is bemutatja, viszont megspékeli azzal, hogy mivan, ha egy nagyobbat beteszünk, és egy kisebbet kiveszünk, miközben feltétel az, hogy nem állhat le a rendszer, tehát online kell megoldanunk.

Először is a rendszer számára láthatóvá kell tennünk az új disket. Majd megcsinálni rá az LVM partíciót. Ezt feljebb már bemutattam, tehát eme ismereteket már feltételezem.

Majd megcsináljuk a megfelelő PV-t belőlle:
# pvcreate /dev/sde1

Ha van új PV-nk a meglévő data VG-t bővítsük vele.
# vgextend data /dev/sde1
# vgdisplay

Amennyiben csak bővíteni akarnánk, most lennénk készen, viszont mi ki akarjuk venni az sdb disket, mert kicsi, ne foglalja a helyet és fogyasszon feleslegesen. Ezért először átmozgatunk minden dolgot az sdb-ról az új sde disk-re.

# pvmove /dev/sdb1 /dev/sde1

Jelen esetben nem volt neki mit átmozgatni, de normál esetben itt szépen átmozgatná az adatait. Ezek után pedig a régi sdb disket simán eltávolíthatjuk a VG-ből.

# vgreduce data /dev/sdb1

CheatSheet az LVM-hez

Mire megérkeztem már nagyban folytak az előkészületek. A hátsó kertben felállított kis mobil grillezőre Gábor már javában pakolta felfele a húsokat. Én sose láttam még előtte olyan "Grill falatokat", de meg kell hogy valljam a kinézetük és az illatuk is fantasztikus volt. Mint megtudtam mélyhűtött kis csomagokban lehet kapni mindenféle ízben, amiket csak némi ideig át kell sütni és kész is.

Ezen túl még grilleztünk pácolt csirkemellet és kukoricás kenyeret is. A héjába sült krumplikról csak zárójelesen szabad megemlékezni, mert kicsit sokáig maradtak a tűzbe így bár tudunk a közepéből kanalazni némi nedűt, nem lett az igazi.

A sütést és a jó időt oldva vittem jófajta Edelweiss búzasört, a kaja után pedig finom vörösbort kortyolgattunk a nappaliban.

Persze a hazaút se volt minden váratlan fordulatoktól mentes. Ugyanis a vonat nem akart megállni a pályaudvaron! Ne kérdezzétek miért nem. Szinte már elhagyta a peront, amikor nagy nehezen csak sikerült neki. A kalauzok se értették mi van, én meg futhattam! :)

Szóval így történt az eset. Sajnos nem sok kép van, mert nagyon jól éreztem magam és így nem volt kedvem fényképezni. Köszönöm szépen a lehetőséget, és persze minden nagyon szép és finom volt. Az összes kép megtekinthető itt.

Plusz egzotikumként gondolkoztam azon, hogy milyen tartóra kellene nekem ezt helyeznem. Először venni akartam valami tartót, de lebeszéltek, hogy egy kis papírcsíkot ragasszak össze. Na a papírcsíkos dologtól féltem, cserébe egy cellux műanyag belső ihletett meg, azóta azon áll.

Természetesen díszes helyen a nagyszobai polcon tartom azóta is és büszén mutogatom mindenkinek.

Előkészületek

Régi verzió ellenőrzése
# ssh -V

Kapcsoljuk ki a régi SSH SMF service-t
Előnyös ha nem SSH-n vagyunk bejelentkezve, hanem CONSOLE kapcsolatunk is van a serverrel.

# svcadm disable ssh
# svcs ssh

Töltsük le a sunfreeware.com oldalról a megfelelő Solaris verzióhoz, és platformhoz való openssh csomagot a függőségekkel együtt és juttasuk el a rendszerünkre

openssh-5.4p1-sol10-x86-local.gz
openssl-1.0.0-sol10-x86-local.gz
zlib-1.2.4-sol10-x86-local.gz
libgcc-3.4.6-sol10-x86-local.gz

Installálás

Tömörítsük ki az openssh-t és a függőségeket
# gunzip *.gz

Először a függőségeket telepítsük
# pkgadd -d libgcc-3.4.6-sol10-x86-local

# pkgadd -d openssl-1.0.0-sol10-x86-local

# pkgadd -d zlib-1.2.4-sol10-x86-local

Most installáljuk magát az új OpenSSH csomagot
# pkgadd -d openssh-5.4p1-sol10-x86-local

Az új ssh binárisok az /usr/local/sbin és /usr/local/bin alatt lesznek elérhetőek.

SSH user és var struktúra létrehozása

Létre kell hozunk egy új SSH user-t és var struktúrát a megfelelő jogosultságokkal.

# mkdir /var/empty
# chown root:sys /var/empty
# chmod 755 /var/empty
# groupadd sshd
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

SSH kulcsok generálása

Hozzuk lére az új ssh-hoz az új kulcsokat, vagy másoljuk át a szükséges kulcsokat.

# /usr/local/bin/ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""
# /usr/local/bin/ssh-keygen -t dsa -f /usr/local/etc/ssh_host_dsa_key -N ""
# /usr/local/bin/ssh-keygen -t rsa -f /usr/local/etc/ssh_host_rsa_key -N ""

Új SMF service létrehozása az új SSH-hoz

Na most, az a gond, hogyha disable-ből visszakapcsolnánk az eredeti ssh service-t, akkor az a régit indítaná el, és tenne magasról az új csomagra, amit telepítettünk. Tehát nincs más, mint új SMF service-t kell létrehoznunk, az új csomaghoz, a régit pedig disable állapotban hagyni.

Először is hozzuk lére az method scriptet

# vi /lib/svc/method/ossh

#!/sbin/sh
# Control Method for openSSH (/lib/svc/method/ossh (c) esm@mnemonic.no 2006)
make_hostkeys () { #making host-keys if they dont exist
if [ ! -r /etc/ssh/ssh_host_dsa_key ] ; then
mkdir -p /var/empty ; chown root:sys /var/empty ; chmod 755 /var/empty
mkdir -p /usr/local/etc ; chown root:sys /usr/local/etc ; chmod 755 /usr/local/etc
/usr/sbin/groupadd sshd ; sleep 1
/usr/sbin/useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
/usr/local/bin/ssh-keygen -t dsa -f /usr/local/etc/ssh_host_dsa_key -N ""
/usr/local/bin/ssh-keygen -t rsa -f /usr/local/etc/ssh_host_rsa_key -N ""
fi
}
case "$1" in
'-u') rm -f /usr/local/etc/ssh_host_???_key* ;;
'-c') make_hostkeys ;;
'restart') /usr/bin/pkill -f -1 -P1 /usr/local/sbin/sshd ;;
'start') make_hostkeys ; /usr/local/sbin/sshd -f /usr/local/etc/sshd_config ;;
'stop') /usr/bin/pkill -f -9 -P 1 /usr/local/sbin/sshd || /usr/bin/pkill -9 /usr/local/sbin/sshd ;;
*)
echo "Usage: $0 { start | stop |restart | -u | -c }"
exit 1
esac
exit 0

Majd állítsuk be a helyes jogosultságot is rajta
# chmod 555 /lib/svc/method/ossh

Most hozzuk létre a manifest file-t
# vi /var/svc/manifest/network/ossh.xml

<?xml version="1.0"?>

<!DOCTYPE service_bundle
SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<!--   Manifest-file for OSSH, put this file
in

       
/var/svc/manifest/network/ossh.xml

       
and run #svccfg import /var/svc/manifest/network/ossh.xml

-->

<service_bundle type='manifest' name='SMCossh432:ossh'>

 

<service

     
name='network/ossh'

     
type='service'

     
version='1'>

 

     
<create_default_instance enabled='false' />

 

     
<single_instance />

 

     
<dependency name='fs-local'

           
grouping='require_all'

           
restart_on='none'

           
type='service'>

           
<service_fmri

                 
value='svc:/system/filesystem/local'
/>

     
</dependency>

 

     
<dependency name='fs-autofs'

           
grouping='optional_all'

           
restart_on='none'

           
type='service'>

           
<service_fmri value='svc:/system/filesystem/autofs' />

     
</dependency>

 

     
<dependency name='net-loopback'

           
grouping='require_all'

           
restart_on='none'

           
type='service'>

           
<service_fmri value='svc:/network/loopback'
/>

     
</dependency>

 

     
<dependency name='net-physical'

           
grouping='require_all'

           
restart_on='none'

           
type='service'>

           
<service_fmri value='svc:/network/physical'
/>

     
</dependency>

 

     
<dependency name='utmp'

           
grouping='require_all'

           
restart_on='none'

           
type='service'>

           
<service_fmri value='svc:/system/utmp' />

     
</dependency>

 

     
<dependency name='config_data'

           
grouping='require_all'

           
restart_on='restart'

           
type='path'>

           
<service_fmri

           
    value='file://localhost//usr/local/etc/sshd_config'
/>

     
</dependency>

  

     
<exec_method

           
type='method'

           
name='start'

           
exec='/lib/svc/method/ossh
start'

           
timeout_seconds='60'/>

 

     
<exec_method

           
type='method'

           
name='stop'

           
exec='/lib/svc/method/ossh
stop'

           
timeout_seconds='60' />

 

     
<exec_method

           
type='method'

           
name='refresh'

           
exec='/lib/svc/method/ossh
restart'

           
timeout_seconds='60' />

 

     
<property_group name='startd'

           
type='framework'>

           
<!-- sub-process core dumps shouldn't restart
session -->

           
<propval name='ignore_error'

           
    type='astring'
value='core,signal' />

     
</property_group>

 

       
<property_group name='general'
type='framework'>

               
<!-- to start stop sshd
-->

               
<propval name='action_authorization'
type='astring'

                       
value='solaris.smf.manage.ssh'
/>

       
</property_group>

 

     
<stability value='Unstable' />

 

     
<template>

           
<common_name>

                 
<loctext xml:lang='C'>

                 
SSH server

                 
</loctext>

           
</common_name>

           
<documentation>

                 
<manpage title='sshd'
section='8' manpath='/usr/local/man'
/>

           
</documentation>

     
</template>

 

</service>

 

</service_bundle>

Importáljuk az új SMF-service-t
# svccfg import /var/svc/manifest/network/ossh.xml
# svcs ossh

Indítsuk el az új OSSH SMF service-t
# svcadm enable ossh
# svcs ossh

Új csatlakozás

Ha most újracsatlakozunk, akkor a kliensünk figyelmeztetni fog, hogy a fingerprint-je megváltozott az SSH servernek, és lehet, hogy át akarnak minket ejteni. Mi viszont tudjuk, hogy ezt mi csináltuk, és az új OpenSSH miatt van az egész. Fogadjuk el nyugodtan és lépjünk is be.

Végszó

Ne felejtsük el, hogy az új OpenSSH új SMF service néven fut. Lehet nagy keveredés miatta. Főleg ha mindkettőt elindítjuk, vagy épp azt hisszük, a disabled "ssh" service miatt nem megy semmi.

- Nem kell hozzá SCSI DISK (NAS használatakor pl).
- Egy Quorum Server esetében több instance több cluster-t is kiszolgálhat.

Hátrányok:

- Kell külön rendszer, OS erre a célra.
- A Qurom Server és Clusterek között (illik) dedikált hálózati kapcsolatot biztosítani.

Quorum Server Telepítése

Szükségünk lesz egy Sun Cluster telepítőre

# ls -lah |grep cluster

Tömörítsük ki a telepítő archív file-t

# unzip suncluster-3_2u3-ga-solaris-x86.zip

Nem szükséges telepítenünk az egész Sun Cluster-t, menjünk a következő helyre a telepítőn belül

# cd Solaris_x86/Product/sun_cluster_qs/Solaris_10/Packages/

Elméletileg a következő három csomagra van szükségünk az alap Quorum Server telepítéséhez:

SUNWscqsman
SUNWscqsr
SUNWscqsu

Telepítsük a megfelelő csomagokat

# pkgadd -d . SUNWscqsman SUNWscqsr SUNWscqsu

Telepítés után a következő helyen lévő két binárist kell hogy lássuk

# ls -lah /usr/cluster/bin/

Quorum Server Konfigurálása

Egyetlen egy config file-t kell editálnunk. Ebben is az instance-ket lehet definiálni. Ahány sort felvezetünk, annyi instance-t definiálunk. Minden instance-hez meg kell adnunk, az instance nevét, a portot ahol figyeljen, illetve azt a könyvtárat ahol a quorum server tárolhatja a futáshoz szükséges információkat.

# cat /etc/scqsd/scqsd.conf

A default file alkalmas az indításra, csupán akkor kell szerkesztenünk, ha ezen változtatni szeretnénk.

Quorum Server Indítása

A következő szintaxissal lehet egy quorum servert indítani:

# /usr/cluster/bin/clquorumserver start [instance]

Amennyiben nem definiáljuk, melyik instance-t akarjuk elindítani, akkor használhatjuk a "+" jelet, úgy mindet el fogja indítani, amely be volt jegyezve a config-ban.

Quorum Server Leállítása

Leállítani pedig az indításhoz hasonló szintaxissal lehet, csupán a start szó helyett a stoppot kell használni.

Quorum Reservációs Kulcsol törlése

Ha van egy Quorum serverünk, amiben vannak már kulcsok is, akkor a következő képpen tudunk kulcsokat törölni manuálisan ha szükséges:

# clquorumserver clear -c sc-cluster -I 0x4308D2CF 9000
The quorum server to be unconfigured must have been removed from the cluster.
Unconfiguring a valid quorum server could compromise the cluster quorum. Do you
want to continue? (yes or no) y

A SUN hivatalos dokumentációja a Quorum Serverről elérhető itt.

Szerencsémre olyan kollégákkal-barátokkal vagyok körülvéve, akik a magyar kulináris különleges szokások, emberek terén jól informáltak. Így kerültem én a Muslincába is, és így szereztem tudomást a tolcsvai étteremről is.

Pár szó a Muslincáról

Gyakorlatilag a város szívében fekvő kis vinotékáról van szó. A kis(csonka)templom mögött fekvő puritán stílusú üzlet, nem kelti az emberekben a fényűző luxus látszatát. Legalábbis számomra semmiképp sem. A kis üzletbe belépve lent mini kör alakú asztalokat találunk, és egy beülős boxot, nagyobb társaságnak. A pult fölött egy kis galéria található, ahol már nagyobbacska (4 személyes) asztalokhoz lehet leülni.

A belső tér, ahogy mondtam az egyszerűség hatását kelti, a finom eleganciával fűszerezve. Ezt csak tovább erősíti a kiszolgáló személyzet is. Egy rokonszenves úr, Dr. Suba Tamás markáns arca fogad szinte mindig az üzletben. Ő szenvedélye a bor és a borozó. Azt kell, hogy mondjam több látogatás után, hogy ő tudja mitől minőségi egy borozó.

Első körben a legpatinásabb magyar borászok borait forgalmazza, akikkel nem csak üzleti kapcsolatban van. Másodsorban mint a kiszolgálás, mint hozzá tartozó történetek nagyon élvezetesek. Harmad sorban a borozóban rendszeresen vannak különböző egyéb kulináris vagy zenés programok, és el is érkeztünk a tegnap esti eseményhez.

Ős kaján este

A kollegáim-barátaim körében nagyon nagy becsben tartott tolcsvai hely mestere, Leeman Pascal adott most egy debreceni estét a Muslincában. Természetesen nem hagyhattuk ki ezt a "zártkörű" estét, ahova előre befizettük magunkat. Az 5000HuF ár elsőre kicsit borsosnak tűnt, de a dolguknak áruk van.

Először is a francia nemzetiségű úriembert emelném ki, aki kifejezetten jól beszélt magyarul, és nagyon kedvesen ismerkedett velünk is. Ezen túl pedig minden fogást maga konferált fel.

A fogások pedig isteniek voltak. Tényleg lenyűgözőek.

Előétel: Spenótos, póréhagymás pite, szarvasgombás íz, szűz olíva olajos zöld saláta
Főétel: Egészben sült sertés karaj, piros ribizli mártás, gesztenyés püré, padlizsán kenyér
Desszert: Csokoládés sütemény, koldus csemegék

Az ételek neve, sokszor bizar volt számunkra is, de mindenkit meg kell hogy nyugtassak, hihetetlen finomak voltak. Én már étkeztem külföldi útjaim során több flancos francia étteremben, és megszoktam, hogy ilyen helyeken az ember nem a mennyiséget, csak a minőséget fizeti meg. A mostani esetben sem roskadoztak a tányérok természetesen, hanem ízlésesen, a megfelelő kompozícióban lettek tálalva. Ettől függetlenül majd szét pukkadtunk a befejező fogás után. Senki nem volt, aki kért volna még repetát, többen viszont majd ki durrantunk.

Egy kicsit meglepő volt számunkra, hogy az esti kulináris élvezetekhez, és a befizetett 5000HuF-hoz az innivalót viszont külön kellett fizetnünk. Mi teljes mértékben rábíztuk magunkat az ajánlásokra, mert természetesen a ház minden ételhez spéci bort ajánlott, és azt kell mondanom tökéleteseket.

Az 5000HuF tartalmazott 1000HuF borkupont, amit végül a nem várt cechbe beszámítottak nekünk, de minimálisan akkor is rossz szájízt adott ez a félreérthető dolog.

Viszont zárásként semmiképp se akarok ilyen hangulatban búcsúzni. Először is mindenkinek ajánlom Debrecen mostani legjobb borozóját a Muslincát itt, majd a tolcsvai Ős Kaján éttermet, itt. Egyetek igyatok, amennyit csak tudtok.
Az este összes képe megtekinthető itt.

Ezt valahol veszélyes security résnek tekintik, mint más cégek ezen információkat használják fel, világszintű riportok készítéséhez.

Többnyire be szokás kapcsolni. Apache webserver esetén ez egy virtualhost file esetében, vagy akár a globális apache configban a következőt jelenti:

Ha tudjuk, vagy tudni véljük, hogy eme információt szolgáltatja a webserver amit távolról ellenőrizni akaunk, akkor a következő mágikus parancs fog nekünk segíteni.

# printf "HEAD / HTTP/1.0\n\n" | nc [SERVER_HOSTNAME] 80 | grep Server

A parancs nagyon egyszerű. Küldünk egy stringet, ami nem más mint egy HEAD HTTP kérés. Ezt a netcat-al (nc) átiránítjuk a kiszemelt host 80-as portjára. A visszakapott információból viszont nekünk csak arra a sorra van szükségünk amiben bennevan, hogy "Server". Ezért erre szűrünk rá.

Az eredmény pedig itt:

A napokban jelent meg egy nagyobb stabil kiadás a FreeNAS-ból. Ez a 0.7.1-es verziószámot viseli magán, és ez az amit én is letöltöttem (innen) és most megpróbálok bemutatni.

Előnézet

Nézzünk néhány zord rendszerjellemzőt:

Alap rendszer: FreeBSD 7.2 (Ehhez tartozó támogatási lista itt)
Támogatott processzor architcetura: i386 és amd64
Minimum háttértár igénye: 128 MB
Minimum memória igény: 256 MB RAM (ZFS esetén viszont minimum 512 MB RAM)

Disk Volume kezelés

• ZFS
• Software RAID 0,1,5
• UFS, Ext2/3, FAT, NTFS
• MBR és GPT partíció
• iSCSI initiator

Hálózat

• 802.1q vlan tagging
• Wireless
• link aggregation
• Wake On Lan

NAS Hálózati protokollok

• SMB/CIFS (Samba)
• AFP (Netatalk)
• NFS
• FTP (ProFTPD)
• TFTP (tftp-hpa)
• RSYNC (client/server)
• Unison
• SCP (SSH)
• iSCSI target

Extra funkciók

• Bittorent client (Transmission)
• UPnP server (FUPPES)
• iTunes/DAAP server (Firefly)
• Webserver (lighttpd)
• Network bandwitdh measure (Iperf)

Monitorozás Riasztás

• S.M.A.R.T (smartmontools)
• Email alert
• SNMP
• Syslog
• UPS (NUT)

Ahogy jól látszik, gyakorlatilag támogatás szempontjából szinte mindent tud ami szóvá tehető, az egyetlen komoly hiányosság a rendszer szintű redundancia, clusterezés.

Installáció

Magam azt LIVE változat ISO file-át töltöttem le, és a következő virtuális konfigurációhoz csatoltam hozzá:
- CPU: 1 mag (2.921 GHz)
- RAM: 512 MB
- NET: 4 darab hálózati kártya ugyan abban a VLAN-ban
- DISK: 3 x 1GB és 3 x 2GB

Boot menü különböző opciókkal

A felbootolt live rendszer menüje fogad

Nem fogom bemutatni az összes menüpontot, majd csak az installálás után. Viszont fontos megjegyezni, hogy LIVE rendszerként is teljes értékű rendszert használhatunk, nem feltétlenül kell telepíteni.

Válasszuk ki a 9-es, Install menüpontot

Az első három pont az installáláshoz tartozik, míg az utolsó három az upgrade-hez, ha egy régebbi verziót kívánnánk frissíteni. Itt is külön tudunk beágyazott "embedded" rendszert, vagy "FULL" teljes rendszert telepíteni. Én ez alkalommal a FULL install-t választottam a menüből.

Figyelmeztetés és jóváhagyás

Válasszuk ki, honnan akarunk installálni

Válasszuk ki, melyik disket akarjuk használni a rendszer telepítés számára

Első fájó pont, nem lehet semmilyen RAID vagy más tárolási hibatűrésre felkészíteni a rendszer installáció alatt, vagy titkosított filesystem-et készíteni.

Mekkora legyen az OS partíció mérete?

Adjunk SWAP-ot is, biztos ami biztos

Maga az install és a logolása

Vegyük ki a CD/DVD médiát, az én esetemben ISO-t, és nézzük a gép indulását

Console menü és konfiguráció

Bootolás után a rendszerünk DHCP alapján kapott IP alapján, alap beállításokkal készen áll a használatra. Ha jól megnézzük akkor a 9-es, install menüpont eltűnt, ez is jól jelzi, hogy már nem a LIVE rendszert használjuk.

Nézzük milyen menüpontokon keresztül tudjuk console módban vezérelni a FreeNAS rendszerünket.

Assigned Interface: Hálózati interface és link detektáláshoz menüs segítség
Set LAN IP address: IP megadása a rendszerünk számára. Ha manuálisan akarjuk osztani, akkor azt szintén itt tudjuk beállítani.
Reset WebGUI password: Ha elfelejtettük a WebGUI jelszavát, itt tudjuk visszaállítani az alapértelmezett admin/freenas -ra.
Reset to factory defaults: Minden beállítást visszaállít az alapértelmezettre. (telepítés utáni állípot)
Ping: Hálózati tesztet végezhetünk a FreeNAS alól.
Shell: Egy bash shell-t kapunk, amin a FreeBSD rendszeren garázdálkodhatunk szabadon.
Reboot system: újraindíthatjuk a FreeNAS-t.
Shutdown: Leállíthatjuk a FreeNAS-t.

WebGUI konfiguráció

Maradjunk annyiban, hogy a Webes adminisztrációs felületre kiforrott az adminisztráció, ha fontos belepiszkálni lehet a console-n keresztül is, de nem ajánlott. Többek között alapból SSH server se fut rajta.

A webes interface alapból nem használ SSL-t, így a sima 80-as portra kell csatlakozunk, ami végül is nem egy nagy érvágás, ha csak belső hálózaton használjuk. Arra vonatkozó információt nem sikerült találnom, hogy mégis milyen böngésző követelményei vannak a webes felületnek. Én magam Firefox 6.3.6-al teszteltem és minden funkció megfelelően működött vele.

Írjuk böngészőnkbe a CONSOLE felületen beállított és kijelzett IP-t

Bejelentkező képernyő rendszer információkkal

Menüpontok

System

Itt kifejezetten a rendszer számára elérhető beállító, illetve vezérlő menüpontokat találunk.

General: Alapvető rendszer információkat tudunk beállítani, illetve jelszót változtatni.

Network

Interface management: Itt tudjuk több hálózati kártya esetén lekezelni, hálózati interface-ket. Nagyon helyesen lehetőség van VLAN ok kezelésére, mi több LAGG (Link Aggregation and Failover)-re is. Fontos, hogy itt bármit babrálunk a beállítások inicializálásához reboot szükséges.

(Amennyiben konfiguráltunk be több OPT névvel látszó interfacet, akkor a menüben meg fog jelenni azon hálózati interfacek beállítása is a LAN management alatt. Maga a felület viszont ugyan az lesz mint a LAN management esetében.)

Hosts: Számomra egy /etc/hosts.allow és /etc/hosts.deny file egybemosása. Tehát tetszőleges service-hez tudunk HOST alapú ACL szabályokat írogatni.

Disk

Management: Egyik legfontosabb menüpont. Itt tudjuk definiálni a NAS storage-nk számára a használandó erőforrásokat és hogy azt hogyan, miként használja. (Ugyan itt tudunk iSCSI initiator-ral iSCSI block device-ket is elérhetővé tenni a NAS számára.) Habár van egy Rescan Disks gomb itt, eddigi tapasztalatom szerint (VMWare) online disk hozzáadásakor nem ismerte fel automatikusan, reboot kellett.

Most akkor adjuk szépen hozzá a diskeket, amiket én elérhetővé tettem. Először is a legördülő listából válasszuk ki melyik disket akarjuk beállítani. Viszonylag sok dolgot be tudunk a disk esetében állítani. Az transfer mode típusát (különböző PIO/DMA módokat); azt, hogy mennyi inaktív idő után kapcsolja ki a diskeket, milyen Power Management-et akarunk használni rá (kell a kakaó, tehát mindig menjen mint az állat, vagy, takarékosan menjen a legkisebb áramot használva), plusz külön a zajosságra való tekintettel is tehetünk beállítást. Természetesen itt található a SMART report bekapcsolása is, ami nem értem alapból miért nincs bekapcsolva, de itt megtehetjük természetesen. Az utolsó rész pedig a funkció szempontjából a legfontosabb, hogy milyen típusú disk is legyen belőle. A lista nagyon gazdag, titkositott disktől kezdve, ZFS, raid, stb.

Én a következő struktúrát alkottam meg:

Fontos, hogy minden beállítást le is kell APPLY-olni, csak akkor állítja elő. Addig csak Initializing sátuszban fognak állni a diskek.

Software Raid: Amennyiben definiáltunk RAID diskeket, itt van lehetőség azokból a tényleges RAID device beállítására. Van minden féle lehetőség, sőt a RAID device esetén a balace algoritmus meghatározására is lehetőségünk van. Ez külön öröm számomra.

Encryption: Itt tudunk disk-ket titkosítással ellátni. Sajnos a meglévő RAID tömböt nem volt hajlandó kezelni, csak disket adhattam meg. Sajnos, ahogy az látszik előre kell gondolkodunk, mert a titkosításnál minden adat el fog veszni, már ha volt rajta előtt valami.

ZFS: Ez a fajta ZFS kezelés egy kicsit furcsa volt nekem. Ugyanis először a diskekből Virtual Device-t kell gyártanunk. A megjelölt diskeknek megmondani, hogy mennyi és milyen rendszerben kapcsolódjon össze. Ez már a zpool lesz. Majd külön a Management részen kell a Virtual Device-t nevesíteni, mountpointot definiálni, és ebből a két menüpont alapján áll össze a zpool.

Amint ez megvan Dataset alatt tudunk tényleges volume-ket létrehozni a zpoolunk-at felhasználva.

Én a következőket állítottam be:

Amúgy információ kinyerés szempontjából a ZFS menüpont nagyon jó. Ezzel a virtual device zpoolos dologgal viszont szemeztem egy darabig.

Format: Itt tudunk diskeket valamilyen filerendszerre megfogmázni.

Mount Point: Itt tudunk külön diskeknek, és akár ISO file-nak is mountpointokat definiálni, illetve az egész mountolást a rendszerünkre beállítani. (FSCK-zni is itt lehet)

Services:

Magam nem tudok olyan dolgot mondani, ami hiányozna ebből a felsorolásból. Szerencsére van egy Status menüpont is, ahol mint lista szerűen tudjuk be-ki kapcsolgatni ezen service-ket.

Természetesen minden service-hez lehetőség van aprólékos beállításra, én magam nem találtam olyat bárhol, amit hiányoltam volna.

Access

User and Groups: Helyi /etc/passwd file alapú user kezelés.

Active Directory: Lehetőség van a felhasználók egy meglévő Active Directory-ból való azonosítására a következő szolgáltatásokhoz: SMB/SSH/FTP/AFP és maga a rendszer.

>

LDAP: Lehetőségünk van a felhasználók kezelésére egy külső LDAP servert használni.

Diagnostics:

Ez alatt a menüpont alat gyakorlatilag minden fontis információ elérhető a FreeNAS rendszerünkről.

Log: Minden log file megtekinthető és letölthető
Information: Kis menüpontokban skatulyázva minden service, szolgáltatás, disk, volume státusz információját le tudjuk kérni.
Ping/Traceroute: Itt tudunk hálózati teszteket végezni a rendszerünkről.
ARP tables: ARP táblákat kérhetjük le.
Routing tables: A hálózati IPv4 és IPv6 táblákat kérhetjük le.

Advanced

File Editor: Webes felületről editálhatunk akármilyen szöveges file-t. Plusz Highlightolás is bekapcsolható.
File Manager: Egy viszonylag butácska és puritán file kezelő, de ha valamit mozgatni kell, akkor hasznos tud lenni. Sajnos feltölteni vele nem lehet.
Command: Parancsot, scriptet, php kódot futtathatunk a rendszerünkön, ebből a menüpontból.

Help

Az itt lévő menüpontok, mind mind egy külső hivatkozások a FreeNAS weboldalaira.

Összegzés

A FreeNAS egy nagyszerű OS, ha valaki NAS építésén gondolkozik. Látszik, hogy a srácok minimal igényekből építkeztek. A tesztem folyamán sok funkció bekapcsolása mellett se sikerült nagyobb memória felhasználásra sarkalnom az OS-t.

Gyors, egyszerű okos. Amit én hiányolok belőle a kicsit enterprise módú gondolkodás. Kiforrottabb és változatosabb telepítés, illetve clusterezési lehetőség. Akkor viszont nagyon komoly vetélytárs válhat belőle. Most még igazán, egy profi otthoni megoldásnak tudnám definiálni.

Ha hozzávesszük, azt hogy menyire elterjedt megoldás, illetve a fejlesztése milyen aktívan, és milyen régóta folyik, akkor érdemes erre alapozni otthoni rendszereket. Nem fogja megbánni az ember.

Hardware

Megjelenés
Ahogy az a képről is jól látszik ez egy komoly kiépítés; saját, SUN rack-ben forgalmazza, gyakorlatilag majdnem készre szerelve. Ezzel próbálta a SUN a profi kategóriában is előnyben részesíteni az egységes, és egyszerű rendszereket.

Ezen felül szubjektív okokból egy tiszteletet és komolyságot sugárzó gép, nem hiába szeretnek vele, vagy mellette parádézni a felsőbb vezetésnél.

Méretek:

Magasság: 191 cm
Szélesség: 85 cm
Mélység: 166cm

Súly: 1122 kg (teljes kiépítésben)

Erő és skálázhatóság

Természetesen, mint minden ilyen nagy és komoly rendszernek, kell hogy legyen egy vezérlő eleme, ami felelős a hardware elemekért, és azok felhasználásáért, csoportosításáért. Ezt itt a System Controller (SC) testesíti meg. Nyilvánvalóan minden alkatrész redundánsnak kell, hogy legyen, ezért mindjárt két SC található, melyek Active-Standby rendszer szerint funkcionálnak. Ha a jobban ismert BLADE rendszerekhez akarnám hasonlítani akkor ez egy BLACE Center frame.

Ezek után jöhetnek a System Board-ok (SB), maguk a BLADE-k. Ezek a vékony kártyák amiket sorba be tudunk csúsztatni a frame-be. Minden egyes SB egy teljes értékű "gépet" testesít meg. Van neki saját CPU, Memória-ja. és megfelelő csatolói.

Egy SB egyesével a következő kiépítésben érhető el:

CPU Architecture: 1.5GHz UltraSPARC IV+ and/or 1.05GHz/1.2GHz/1.35GHz UltraSPARC IV and/or 1.2GHz UltraSPARC III processors; Superscalar SPARC V9, ECC protected
CPU Cache per processor: Level 1: 64 KB data and 64 KB instruction per pipeline Level 2: 2 MB on-chip Level 3: 32 MB external
Memory: Maximum 64GB per Board

(SUN Uniboard Matrix link)

Összesen 18 SB-al bővíthető a E25K. Ezáltal a következő maximális konstrukció alakítható ki:

Processor: Maximum 72 processors, 144 simultaneous threade.
Memory: Maximum 1.15 TB per domain
I/O: Up to 72 hot swappable PCI-X I/O slots, 54 slots are 90MHz, 18 slots are 33MHz. supports 10/100 BaseT Ethernet, Gigabit Ethernet, UltraSCSI (LVD and HVD), ATM, FC-AL, HSI, and SCI

Tároló kapacitás

Az E25K alapvetően semmilyen adat tárolási funkcióval nem rendelkezik, csupán a I/O portok vannak kialakítva hozzá. Tehát ha valaki egy ilyenbe ruház annak szükséges gondoskodnia valamilyen storage-ről még pluszban. Ez szokta többnyire a másik "szekrényt" reprezentálni az E25K mellett (ami szintén egy "szekrény").

250+ TB storage kezelését teszi lehetővé a kiépítés. Ezt pedig mind Fibre Channel (1GB és 2GB) vagy UltraSCSI csatolóval tehtjük meg.
Az fontos, hogy bootoláshoz viszont a következő tároló megoldásokat ajánlja a SUN:
Sun StorageTek 3120, Sun StorageTek S1, Sun StorageTek D240, Sun StorageTek 3510, Sun StorageTek 3310, Sun StorageTek 9990

A teljes elméleti I/O sávszélesség 35.8 GB/s-ig tornázható fel.

Rendszer a rendszerben - Domain

Tehát már ismerjük a vasat, nézzük hogyan tudjuk kezelni. Ott van nekünk maximális kiépítésben 18 System Board (SB), amikre más esetben mindre tudnánk egy Solaris-t installálni. Mostani esetben viszont lehetőségünk van egy logikai egységet képezni, ami alá tetszés szerint csoportosíthatunk hardware erőforrásokat.

Ez a logikai egység, kötet lesz a DOMAIN. Egy domain tehát egy olyan "virtuális" gép, ami reprezentál a külső világ felé egyetlen hardware eszközt, de alatta tetszés szerinti SB és ezáltal resource kezelhető. A System Controller (SC) feladat ezen logikai egységek kezelése, felügyelete, és vezérlése.

A SC amúgy egy Solaris OS-t tartalmazó mini gép, amin vagy egy System Management Service (SMS) van telepítve. Ez az egész E25K vezérlésének a lelke gyakorlatilag. (SUN SMS link)

A SC-n kiadva a showplatform parancsot a következő hasznos információkhoz juthatunk:

# showplatform

A fenti képen jól látszik, hogy A-tól Q-ig van lehetőségünk DOMAIN-eket kezelni. Az itteni esetben pedig két domain létezik. Lentebb pedig jól látszik, hogy a Domain Status alatt Running Solaris szerepel. Tehát bennük aktívan fut Solairs OS.

Amennyiben a nem DOMAIN-ek szemszögéből közelítünk, hanem SB felől akkor a showboards parancsot adjuk ki az SC-n.

# showboards

Fentebbi képen jól látszik, hogy itt már a SB-k és I/O modulok szemszögéből láthatjuk a 25K-t. A Type of Board esetében láthatjuk milyen típusú kártyával van dolgunk. Ha Empty Slot szerepel, értelemszerűen az a bővítőhely üres. A Board Status-a aktív és PWR mező alatt látjuk be is van kapcsolva. Az egész végén pedig láthatjuk melyik DOMAIN-hez tartozik. Itt jól kitűnik, hogy egy DOMAIN-hez több SB is hozzá lehet rendelve, de egy SB csak egy DOMAIN-hez tartozhat.

Hardver Diagnosztika

Egy SB-nek is lehet millió kis kütyüje, aminek egyetlen meghibásodása is kihathat az egész kártyára. Egy parancs segítségével lekérhetjük az összes Component Health Status (CHS) információt:

# showchs

Mivel ez egy végtelen futó listát eredményez, rászürhetünk a NEM "OK" üzenetekre, illetve lehetőségünk van, a -c kapcsoló után argumentumként megadni minek a státuszára vagyunk kíváncsiak.

# showchs -c SB5

Illetve részletes információkhoz is juthatunk, ha a -v kapcsolót is használjuk. Ilyenkor olyan információkhoz is hozzájuthatunk, hogy esetleg régebben, volt e rossz valami.

# showchs -v -c SB5

DOMAIN és Online resource kezelés

Tehát van már DOMAIN-ünk, amihez hozzárendeltünk sok-sok hardware erőforrást, System Board-ot (SB). Persze felvetődik a kérdés mi történik akkor, ha az egyik SB feladja a harcot, vagy mi döntenénk úgy, hogy eltávolítanánk a DOMAIN-ből. Jó hír hogy erőforrások mozgatása online megtehető (persze egy kivétel van, ha a SB memóriájában kernel specifikus adatok tárolódnak, akkor azt nem lehet evakuálni).

SB hozzáadása
Pontosabb leírás inkább, hogy egy DOMAIN-hez hozzárendelünk egy még szabad SB-t. A -d kapcsoló után kell megadni melyik DOMAIN-hez akarjuk hozzárendelni, majd -r után azt, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

# addboard -d A -r 2 -t 600 SB2

SB törlése
Pontosabb leírás inkább, hogy megszüntetjük az SB valamely DOMAIN-hez való hozzárendelését. Ezzel szabaddá téve.A parancs után a -r követően azt kell megadn, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

# deleteboard -r 2 -t 900 SB2

SB hozzárendelése egyik DOMAIN-től egy másik DOMAIN-hoz

Lehetőségünk van, egy paranccsal megoldani egy deleteboard és addboard metódust. A -d kapcsoló után kell megadni melyik DOMAIN-hez akarjuk hozzárendelni, majd -r után azt, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

Domain leállítása

Akkor az már világos, hogy a DOMAIN az gyakorlatilag egy logikai SPARC masina. Akkor vigyük le OK PROMPT-ba. Adjuk ki a következő parancsot a DOMAIN-en belül, és ne a System Controlleren :)

# init 5

Nézzük most mi látszik a System Controller felől:
# showplatform

Jól látszik, hogy most a Domain Status az megváltozott. Ekkor a domain továbbra is működő. Csupán a benne lévő OS kapcsolt le.

Ha a DOMAIN-t mint logikai gépet ki akarjuk kapcsolni, akkor el kell fordítanunk a logikai kulcsát a gépnek, akár csak egy fizikai esetében.

# setkeyswitch -d A off

Jól látszik, ahogy a logikai gépünk, a DOMAIN leáll, és ezáltal az eddig általa fogott eszközök is kikapcsolnak.

Domain elindítása

# setkeyswitch -d A on

Elfordítjuk az A DOMAIN virtuális kulcsát ON-ra. Ezzel szépen bekapcsolja a szükséges hardware elemeket, és elindul a rendszer. Pontosabban még csak a POST (Power-On Self Test).

# showplatform

A logikai rendszer, a DOMAIN is fogja és végigteszteli szépen a hozzá kapcsolt hardware elemeket.

A POST szintjét a /etc/opt/SUNWSMS/SMS1.6/config/A/.postrc file-ban lehet meghatározni (persze itt az A domain postját tudjuk állítani).

Egy magasra emelet POST szint és több System Board esetében ez akár több óra is lehet. A mi mérésünk szerintm 10 SB 96-os POST level-el 3.5 óra volt.

Túlélőparancsok E25K-hoz

SMS userek listázása
# smsconfig –l platform

Console kapcsolat System Controllerről egy DOMAIN-hez (-d után a DOMAIN)
# console –d A

Console kapcsolatból kilépés
~.

Break signal küldése, ami OK PROMPT-ba visz
~#

System Board Firmware flashelése
# flashupdate -f $SMSOPT/hostobjs/sgcpu.flash SB3

Domain resetelése (-d után a DOMAIN)
# reset –d A

Mely folyamatok tartoznak az SMS-hez?
13 ( dsmd,efe,esmd,fomd,frad,hwad,kmd,mand,mld,osd,pcd,ssd,tmd)

Mely agent-ek tartoznak az SMS-hez?
2 ( dca , dxs)

Hol találhatóak a fontosabb log file-k?
Platform logok:
/var/opt/SUNWSMS/adm/platform/messages
Domain logok:
/var/opt/SUNWSMS/adm/domain_id/messages
Domain console:
/var/opt/SUNWSMS/adm/domain_id/console

Hogyan nevezhető el egy DOMAIN?
# addtag –d A testname

Hogyan törölhető egy DOMAIN neve?
# deletetag –d A testname

SMS és CFGADM összehasonlító táblázat

Amit nagyba tud az SMS azt kicsibe tudja a sima cfgadm is kicsiben. Erről íme egy rövid összehasonlító táblázat.

Végszó

Sajnos a trend azt mutatja, az ilyen nagy gépeknek leáldozóba van a soruk. A válság virtualizáció felé int, és kicsi, olcsón adminisztrálható osztott rendszereké a jövő.

A mi E25K-nk is így tűnt el a semmiben. Ami egyszer robosztus, hivalkodó és csillogó volt, az most drága, pocsékló és felesleges.

Nekem ettől függetlenül nagy élmény marad a 25K és a vele töltött adminisztráció. Itt elérhető egy rövid datasheet az eszközről, a SUN marketingesek tollából.

A félreértések

A következő dolgokat lehet a iADról tudni a blogos híradások szerint:

"... Átlagosan három percenként egy reklámot fogunk látni...", "... Az Apple a Alkalmazásokba akar építeni reklámokat ...", "... az Apple iPhone OS fogja vezérelni a reklámokat ..."

Ebből pedig mindenkinek az jött le, hogy az iPhone három percenként el fog sötétedni, és kötelezően végig fogunk nézni egy-egy buta reklámot.

Mi is, hogy is ez az iAd?

Na kérem szépen, ennyire az Apple se hülye! :) Természetesen nem kell otthon az ágyban forgolódni emiatt. Talán mint sokan mások, én is megnéztem az eredeti videó anyagot a prezentálásról. Szó sincs semmi ilyen felhasználói élmény megzavarásáról.

Steve elmondta, hogy szeretnének segíteni az ingyenes APP-ok készítőinek, és ezzel a fejlesztőknek, hogy továbbra is legyen sok, és minőségi ingyenes tartalom is iPhone-ra. Ez üdvözítő. Persze mint minden okos kapitalista üzletember, úgy próbál ösztönözni, hogy ad lehetőséget pénzkeresésre.

Steve azt mondja, fejlessz ingyen iPhone-ra és iPad-ra alkalmazásokat, és ugyan úgy mint a Google Adsense vagy más egyéb banneres vagy nem banneres hirdető egy weboldal esetén, egy részét az alkalmazás felületének jelöld ki az iAD számára. Ezen a részen pedig a rendszered, vagyis az Apple minden féle oda szánt tartalmat fog megjeleníteni.

Na és itt jön az a mágikus három perc, mert ott három percenként fognak mutatni reklámokat. Szerintem nem egy olyan nagy érvágás, főleg ha folytatom is Steve forradalmi ötletét.

A helyzet az az, hogy a Google-nél nincs a világon jobb cég, aki releváns reklámokat tudna megjeleníteni keresésekhez. Ez tény. Ezért az Apple meg se próbál keresésekhez reklámot eladni. Egyszerűen azért, mert az almás cég azt mondja, aki a telefonját használja, az főleg nem keres szabadidejében, hanem valamilyen alkalmazást indít el. Ezért ők ott akarnak piacot nyerni, és valljuk be, már van annyi iPhone, iPod touch, és lassan iPad is, hogy lesz piacuk.

Reklám Forradalom

Mi volt eddig egy reklám? Egy animált gif, villogzó flash banner, egy Google Adsense link. Bármi is, ha rákattintott az ember elvándorolt jó messzire az eredeti oldaltól. Az pedig, hogy a linkre kattintva mi fogadt minket mindig lehangoló volt.

Ezen akar változtatni Steve és a csapata. A reklámokat fel kell turbózni, és új, izgalmas formátumban teríteni a vásárlóknak, hogy tudják ha rákattintanak egyre, akkor a mögött nem valami hasztalan, csúnya, dolog lesz, hanem szép, hangulatos, és garantált minőség.

Na ez az iAD, ami nem más mint egy mini HTML5 oldal. Videókkal, hang anyagokkal, dinamikus animált tartalommal, akár csak egy nativ alkalmazásban. A reklámok pedig filozófiájukban is meg fognak változni. Én magam először nem is értettem hol itt a reklám?

Vegyük példának az első bemutatott Toy Story reklámot. A képernyő aján egy fél ujjnyi kis csík volt. Amire rákattintva egy bejött egy kis videó, majd egy menü. Ahol a Toy Story 3 legújabb filmjét promótálták. Lehetett letölteni háttérképet iPhone-ra, megnézni ízelítőket a filmről, játszani kis mini játékokat, és végül az egyik menüpontban le lehetett kérni a GPS koordinátáid által lekért adatok alapján, az aktuális helyzetedhez képest, hol tudod leghamarabb megnézni a Toy Story-t.

Más alkalmazásoknál is ez volt a helyzet, mint releváns bevételi forrásként bevásárló listákat lehetett csinálni a reklámban felbukkanó termékekből és megrendelni, és sorolhatnám.

Szóval srácok és lányok. Az iAD nem szól másról, mint minőségi reklámokról. Olyan reklámokról, amire ha rákattintasz, élvezet megnézni, és ezáltal élvezet költeni. Engem meggyőzött Steve, hogy ahogy a PC gyártóknak feladták a prémium kategóriában a leckét, úgy a Google-nek, szintén fel fogják prémium kategóriában adni a leckét. Mert a kis csóró weboldalas embereknek a Google Adsense a világ legjobb reklámozási formája, most és a jövőben is, de egy nagy cég számára, ahol fontos a jó megjelenés, és a minőség, az iAD-al akar reklámozni majd.

Nekem legalábbis ez jött le. Fontos megjegyezni, hogy ez csak előzetes bemutatás volt, hogy mi vártható végleges kiadásokban az még persze homály fedi, de ha én fejlesztő lennék, én örültem volna ennek az új reklámozási bejelentésnek.

A következőkben azokat a Mac Os X által alapból nem értelmezhető file formátumokat fogom bemutatni, amikkel eddig dolgom volt, és sikerült is valamilyen program által átkonvertálni, vagy mountolhatóvá tenni az almás rendszer alá is.

Bin + Cue

Főleg régebbi Windows-os időkből ránk maradt BIN + CUE file-ból álló párost nem könnyen eszik meg minden. Hála egy elég fapados és ingyenes konverternek viszont minden gond nélkül ISO file-t tudunk varázsolni belőle.

Ehhez le kell töltenünk a BinChunker nevű kis toolt, innen. A legismertebb Linux, Solaris, Mac Os X platformokon működik.

A továbbiakban Terminal alkalmazás segítségével kell haladnunk. Amennyiben megvan a bináris másoljuk egy biztos helyre és adjunk neki futtatási jogot (chmod +x FILE_NEVE)

Ezek után a következő szintaxis segítségével tudjunk elindítani a konvertálást:

./bchunk proba.bin proba.cue proba.iso

Ahogy jól látszik, meg kell hívnunk a binárist, első paraméterként a BIN file elérési útvonalát kell megadni, majd a CUE file elérési útvonalát, végűl a létrehozandó új ISO file elérési útvonalát, hogy hova jöjjön létre az új file.

Nézzük egy éles példán:

DAA & GBI

Mielőtt találkoztam volna vele, előtte sose hallottam róla. Minden esetre meggyűlt már a bajom ilyennel is. A megoldás itt egy sokkal kezelhetőbb program segítségével jön. A grafikus program induláskor, egyből kéri is, hogy adjuk meg hol található a DAA file. Majd ebből ő automatikusan ISO-t generál.

A DAA converter ingyenesen letölthető innen.

Seven (7) Zip

Ez egy kicsit kakukktojás, mert nem igazán image file, hanem sima tömörítő alkalmazás, én mégis megemlítem a 7zip tömörítőt Mac Os X alá. Ingyen van. Drag and Drop működik pofon egyszerűen egy kis grafikus ablak segítségével. A készítő weboldala megtalálható itt.

MDF

Az Alcohol 120% bin image file formátum is közkedvelt Windows-on. Egy megint csak elég fapados Apple Script segítségével tudunk MDF file-ból ISO-t generálni. Nincs más dolgunk, mind az MDF file-t rádobnunk az Apple Script file-ra, és minden megy is. A kis stuff ingyen elérhető itt.

UIF

Végül de nem utolsó sorban itt az UIF formátum. Szintén általam ismeretlen volt ezidáig. Cserébe az ingyenes grafikus tool segítségével egyszerűen konvertálhatjuk ISO image bármilyen UIF állományunkat. Egyszerűen ki kell browse-olnunk a megfelelő UIF file-t és automatikusan indul is a művelet. A tool weboldala elérhető itt.

Hozzá kell tennem, hogy a felvétel teljesen ad-hoc módon történt. A felvétel előtt 5mp-el hamarabb kaptam meg a szöveget, és se átolvasni, se a figurát megfelelőképp kitalálni nem volt idő, sajnos egy helyen el is sikerült nevetnem. Az amatőrségtől eltekintve viszont kellemes emlék marad.

Solaris Administrator's Quick Reference

Solaris QuickSheet

Sun Cluster commands

Solaris Volume Manager Commands

A jövőben a Solaris-t letöltő emberek egy 90 napos limitációt kapnak. Ezzel veszi elejét a cég annak, hogy bárki csak úgy komolyabb összegek nélkül használhassa az üzleti rendszerét. Akinek ingyen kell valami, válassza az OpenSolaris-t.

A letöltési oldalon a következő új szöveget kapják a felhasználók email-ben:

Please remember, your right to use Solaris acquired as a download is limited to a trial of 90 days, unless you acquire a service contract for the downloaded Software.

Ez viszont egy nem meglepő lépés az Oracle-től. Az adatbázis cég számára elsődleges feladat megzabolázni, az eddigi vad és szertelen üzleti koncepciót, mielőtt rendszereit ezekre építené. Talán a jövőben ezen kapuk becsukása után felértékelődik Solaris adminisztrátornak is lenni, de várjuk ki a végét. Én remélem, hogy ez a közösség számára nem túl biztató húzás még hozhat eredményeket is.

Először is, szörnyű ízű, zöld, "Pecás" italt kell fogyasztani. Azon túl, hogy egy szar, az olcsó ára, és hihetetlen gusztustalan élénkzöld színéről lehet megismerni. Ahogy a srácoktól megtudtam, sose szokott elfogyni.

A második a sátánista hangulat. Sötét kell, és sok-sok gyertya, mécses, füstölő, meg miegymás. Ezek után jön a három debreceni múlttal rendelkező fiatal, felsőoktatás rögös ösvényeit végigküszködő fiatalember. Kell még, egy zokni, annyira apróval amennyivel épp rendelkezünk, és kezdődhet is a zenélés.

Alapvetően a srácok imádják a dalszövegeikbe beleszőni a sátánista, fekete mágiás témákat, annak ellenére, hogy mindhárman távol állnak tőle. Egyszerűen csak a poén kedvéért.

A több órás együtt zenélést sűrű ivászatok, és evések szakították félbe. Természetesen teljesen amatőr módszerekkel rögzítve lettek a számok is, plusz amennyire a hangulat adta, én is fényképeztem, és videóztam őket.

Én köszönöm szépen az egybegyűlteknek a meghívást, hogy ott lehettem. A metánbusz hivatalos oldala megtekinthető itt, illetve az én általam készült összes kép és videó itt.