FreeBSD a szerveremen :)

FreeBSD-all

Halihó!

Elkezdtem írni egy wiki-t azon okból, hogy hamarosan FreeBSD kerül a szerveremre (amelynek elsődleges feladata a javaforum.hu hostolása lesz). Érdekelne vélemény, javaslat, ötlet, hogy érthető-e, esetleg valahol kihagytam-e egy fontos lépést, mivel nekem triviális, de egy új FreeBSD felhasználónak annyira nem, stb.

Az URL: http://wiki.javaforum.hu/confluence-2.8.2/display/FREEBSD/FreeBSD+in+my…
--
http://www.javaforum.hu

  • 8658 megtekintés

Nem úgy értettem, hogy ültesd át cikk formába, hanem csak azt, hogy beküldesz egy cikket arról, hogy ezt meg ezt írtam, ez van benne, itt található. És a végén belinkeled az írásod. Mintha egy levlistára postáznád. Az előnye annak ha cikként van beküldve, hogy úgy megjelenik az rss hírcsatornában, a napi hírlevélbe is és valószínűleg több emberhez jut el, mint ha csak a fórumban van. :)

--
trey @ gépház

Ha megáll a syslogd akkor tökmind1, hogy socket, tcp, udp vagy bármi csoda. Megállt. A legkisebb overheadje annak van, ha a normál gépen syslogolsz (ízlés szerint syslog-ng) és socket-tel. Ha a hálózatod más gépeiről is gyűjtesz logot oda, akkor esetleg van értelme jailbe tenni a logszervert, de ez már elég paranoid. :) Az elmúlt 6 évben kb. talán 1x fordult elő hogy valamelyik gépünkön kihalt a syslog és szerintem nem is BSD-s volt, illetve vmi brutál DoS-t kapott talán. Egy másik szempont hogy mennyire karbantartható, mert mégegy plusz jailt update-elgetni nem mindíg jó tipp.

Azok az alkalmazások, amik direktben vagy majdnem direktben ki vannak téve a juzerek felé sokkal hamarabb borulnak. (Lásd céges buli vagy hasonló minisite-ja, amit egy adott nap délután egyszerre 200-an kezdtek el nézni ugyanarról a X*10mbit-es céges béreltvonalról. Persze a ügyfél nem szólt hogy hát lehet vmi kis forgalom, ami beérkezik, hiszen "óhát úgyis kevesen nézik", hja csak egy X2100-ast sikerült fektetniük az első rohammal... :D)

Ha megáll a syslogd akkor tökmind1, hogy socket, tcp, udp vagy bármi csoda. Megállt.

Ezt értem... gondolom mindegyik megoldás védett az ellen, hogy ha pipe-ba loggolok és nem tudja továbbküldeni, akkor ne blokkolja a pipe-on keresztül a loggoló alkalmazást...

Egy másik szempont hogy mennyire karbantartható, mert mégegy plusz jailt update-elgetni nem mindíg jó tipp.

Noigen... éppen azon gondolkodom, hogy miképp tudnék jól karbantartható jail-t csinálni, és arra jutottam, hogy a ZFS képes két snapshot közötti különbséget exportálni fájlba... tehát maga a jail fájlrendszere nem lesz ebben benne, mert azt klónoztam. A template jail-t frissítem, teszek rá snapshot-ot, majd fogom a frissítendő jail-t és:
* Leállítom
* Teszek rá snapshot-ot
* Elmentem az eredeti és az új snapshot közötti különbséget, itt gyakorilatilag azok a fájlok vannak, amit felmásoltam.
* Eldobom a jail fájlrendszerét
* Csinálok egy új klónt a frissebb template-ből
* Visszatöltöm a kimentett különbséget
* Elindítom

Nem néz ki olyannyira problémásnak, még akár automatizálható is lehet...
--
http://www.javaforum.hu

( nomad84 (nem ellenőrzött) | 2008. 08. 11., h – 09:18 )

Remek munka.

++ mostly harmless

( tgyurci v | 2008. 08. 11., h – 12:28 )

Szia!

Úgy látom, hogy most Glassfishen fut a javaforum.hu. A FreeBSD-s szerveren is Glassfisht fogsz használni? Ha igen, akkor hogyan, ha nem, akkor helyette mit?

szerk.: u.i.: szerintem jók lettek az eddig elkészült részek

Úgy látom, hogy most Glassfishen fut a javaforum.hu. A FreeBSD-s szerveren is Glassfisht fogsz használni? Ha igen, akkor hogyan, ha nem, akkor helyette mit?

Feltettem a jdk6-ot (java/jdk6), és a linux-os glassfish-t, felkonfigoltam cluster módban, és elindult, beléptem az admin konzolra, beledeployoltam egy egyszerű alkalmazást és ment.
--
http://www.javaforum.hu

Igen, de mint írtam: "Nos, alapvetően OpenSolaris került volna a szerverre, de egyelőre csapnivaló a csomagválasztéka és sok helyen még nagyon érződik a fércmunka szaga. Régebben FreeBSD szervereket üzemeltettem (ha jól emlékszem, egészen a 6.0 verzióig), így most kipróbáltam az idén megjelent FreeBSD 7.0 rendszert. Esélyes volt még a Solaris 10 is, de ennek még gyatrább a csomagkezelése, így hamar elvetettem ezt az opciót."
--
http://www.javaforum.hu

( szume | 2008. 08. 21., cs – 14:04 )

Gondoltam nem nyitok új topicot a kérdésemnek. Mennyire megbízható a zfs? Elég fiatal filerendszer. Konkrétan backup szerverre szeretném rakni és a tömörítés miatt nagyon jó lenne.

Valoban experimental meg a hivatalos statusza ha jol tudom, de javitsatok ki ha nem, en viszont hasznalom backup-nak tobb tiz TB-os volume-ot es semmi bajom sincs vele. Igaz, Solaris 10-en es rendszeresen patch-elve.

-- Soha ne vitatkozz idiotakkal! Lesulyedsz az O szintjukre es legyoznek a rutinjukkal !!! --

Akkor talán nem lesz vele gond BSD-n sem. A topicindító wiki nagyon inspiráló és meggyőző.

Jelzem úgyis, ha gond lenne, egyelőre szépen megy már a szerveren, bár jelentős terhelés még nem volt rajta.

Bónusz kérdés: 


da0 at mpt0 bus 0 target 0 lun 0
da0: <LSILOGIC Logical Volume 3000> Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers
da0: 237464MB (486326272 512 byte sectors: 255H 63S/T 30272C)

Ez jelenleg eléggé gyéren teljesít (6MBájt/s írás és 60MBájt/s olvasás): 


[root@freebsd:~]$ dd if=/dev/zero of=/root/testfile ibs=65536 count=16384
16384+0 records in
2097152+0 records out
1073741824 bytes transferred in 161.619783 secs (6643629 bytes/sec)
[root@freebsd:~]$ dd if=/root/testfile of=/dev/null ibs=1024
1048576+0 records in
2097152+0 records out
1073741824 bytes transferred in 16.862023 secs (63678115 bytes/sec)

Ez akár lehet üzemszerű is, bár eléggé nagy szégyen lenne egy IBM X3250 szervertől... :)
--
http://www.javaforum.hu

Kicsit utánaolvastam a problémának, úgy látom mások is szívnak az mpt driverrel, a write cache nem működik valamilyen oknál fogva.

[...]

Na, keresgéltem, találtam egy megoldást:
hw.mpt.enable_sata_wc=1

UFS2 fájlrendszeren: 


[root@freebsd:~]$ dd if=/dev/zero of=testfile ibs=64k count=32k
32768+0 records in
4194304+0 records out
2147483648 bytes transferred in 44.881676 secs (47847671 bytes/sec)
[root@freebsd:~]$ dd of=/dev/null if=testfile ibs=64k count=32k
32768+0 records in
4194304+0 records out
2147483648 bytes transferred in 37.648894 secs (57039754 bytes/sec)

ZFS fájlrendszeren: 


[root@freebsd:/tmp]$ dd if=/dev/zero of=testfile ibs=64k count=32k
32768+0 records in
4194304+0 records out
2147483648 bytes transferred in 105.221092 secs (20409251 bytes/sec)
[root@freebsd:/tmp]$ dd of=/dev/null if=testfile ibs=64k count=32k
32768+0 records in
4194304+0 records out
2147483648 bytes transferred in 34.791732 secs (61723965 bytes/sec)

Kissé vissza van fojtva a ZFS, mert a gépben csak 1G memória van egyelőre. De így már más a helyzet. :)
--
http://www.javaforum.hu

Nálam sajnos megdöglött a gép a második nap, az okát egyelőre nem tudom, mert nem tudtam neki távoli konzolt kérni (jövő héten kap IP-t a management portra), egyelőre kértem most egy újraindítást, és megnézem írt-e valamit logba. Ahogy nézem, a find futott, amely jelenthet I/O terhelést, ami jelenthez ZFS halált, de ahogy olvastam, ilyenkor zfs státuszban maradna. Hm... itt az utolsó `top`, amit SSH-n át tudott küldeni. Ami érdekes, hogy a gép `ping`-re válaszol, a portokat nyitottnak mondja, de minden olyan process, ami hallgatna ezeken a portokon `wait` állapotban van. 


last pid: 21246;  load averages:  0.00,  0.00,  0.00         up 0+05:53:07  03:13:03
87 processes:  1 running, 68 sleeping, 18 waiting
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.4% interrupt, 99.6% idle
Mem: 17M Active, 36M Inact, 921M Wired, 3812K Cache, 8560K Buf, 192K Free
Swap: 4096M Total, 3740K Used, 4092M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
19102 root          1  44    0  8108K  2032K CPU1   1   0:03  0.00% top
21244 root          1 -16    0  4604K  1432K vmwait 0   0:02  0.00% find
 1450 auth.gabor    1  44    0 33756K   840K select 0   0:02  0.00% sshd
  789 root          1  44    0  9432K  1616K select 0   0:00  0.00% ntpd
15769 root          1   4    0  4600K  1260K kqread 1   0:00  0.00% dovecot
 1457 root          1   8    0  9012K     0K wait   1   0:00  0.00% <bash>
86889 root          1  76    0 10732K  2848K pfault 0   0:00  0.00% sendmail
 2034 auth.gabor    1  44    0 33756K     0K select 0   0:00  0.00% <sshd>
17857 root          1  44    0 10732K     0K WAIT   1   0:00  0.00% <sendmail>
18573 root          1  44    0 13764K     0K WAIT   1   0:00  0.00% <syslog-ng>
18640 root          1  44    0 10732K     0K WAIT   0   0:00  0.00% <sendmail>
  825 root          1   8    0  6744K     0K WAIT   0   0:00  0.00% <cron>
15773 root          1   4    0 13080K  2528K kqread 0   0:00  0.00% dovecot-auth
86809 root          1  44    0 13764K     0K WAIT   0   0:00  0.00% <syslog-ng>
  670 root          1  44    0  5688K     0K WAIT   0   0:00  0.00% <syslogd>
15762 root          1   4    0 15372K     0K WAIT   0   0:00  0.00% <master>
 2039 root          1   8    0  9012K     0K wait   1   0:00  0.00% <bash>
86899 root          1   8    0  6744K     0K WAIT   1   0:00  0.00% <cron>
15784 root          1   8    0  6744K     0K WAIT   0   0:00  0.00% <cron>

--
http://www.javaforum.hu

Nincs oskoribb allapotban, mar 1 eve ugyanazo na szinten van mint FreeBSD -n, sot valoszinuleg jopar dolog ertelmesebben van implementalva. Ugyanugy hasznaalhatsz ffs2 -t is ha akarsz.

Az hogy miert nincs ZFS? Mert inkabb csak hoax van korulotte, mint ertelem, a license elfogadhatatlan es az egesz nagy szar :)

Pont 2-3 napja beszeltuk, azt hogy Net/FreeBSD vilagnak goze sincs arrol, hogy mi folyik az OpenBSD haza tajan.

Valóban nem követem az OpenBSD-t, de a FreeBSD-ben pont az elmúlt (cirka) egy évben voltak ezen a téren változások: SMP, kvótakezelés, journaling, egy rakás fix (ami persze lehet, hogy az OpenBSD-ben nincs, vagy már javított) mittudoménmi. :)

Az UFS-hez képest azért a ZFS-nek van sok értelmes dolga, függetlenül attól, hogy a Sun csinálja a hype-ot.
És az UFS mindettől függetlenül őskori, egyre kevésbé illeszkedik a modern tárolórendszerekhez (főleg az, ami a *BSD-ben van).

Az utolsó ponton aktívabb kommunikációval lehetne javítani. Például rendszeres státuszriportokkal, amelyek után közösen örülhetnénk. :)

Varj SMP ... kb 7 eve probalnak megszabadulni a giant locktol? Es kozben ott volt az 5-s sorozat amirol inkabb ne is beszeljunk. Ezt mi nem igy csinaljuk, mi is szepen lassan ... NAGYON lassan ... tavolitjuk elfele a giant lockot de ez nem fog a rendszer minosegere menni. A FreeBSD es OpenBSD fejlesztesi stilusa nagyon nagyon kulonbozik (szerencsere). Igen oskori ez biztos es lassan eljar majd felette az ido, de mindeki implementalhat egy olyan filerendszert ami szerinte megfelelo a feladatra. Nem kell kotelezoen ZFS -t hasznalni mindenkinek.
Sajnos nem vagyok FS hacker de ha jol emlekszem akkor mi nem egeszen ugy akarjuk megvalositani a journalingot mint ahogy azt masok tettek. Sot nem is journaling lesz, de komolyan nem tudok tobbet mondani mert nagyon nem emlekszem es nem akarok hulyeseget beszelni.
Nem a kommunikacioval van baj. CVS logokat mindeki tud olvasni. Ha mi tudjuk olvasni a logokat es jokat rohogni rajta akkor masok miert ne tudnak?

Mester... miért kell az OpenBSD mögé ez a scientology jellegű érvelés? :)

Én elhiszem, hogy jó az OpenBSD, de ennyire nem jó. Egy csomó feladatra pedig egyátalán nem jó. A FreeBSD se jó egy csomó feladatra. A Linux se jó egy csomó feladatra, és vannak olyan feladatok, amire egy AIX vagy egy OS/400 a kiváló. Nincs univerzális oprendszer, bármennyire is szeretnéd ezt hinni.

Itt és most FreeBSD a téma, nem az OpenBSD.
--
http://www.javaforum.hu

AIX például tud p vason processzort kérni, 0,1 CPU felbontással, ugyanez megy memóriával is, tehát ha egy másik LPAR igényel több erőforrást és engedélyezve van neki, akkor megkapja. Linux-al nem megy még ilyen szépen.

Az OS/400 meg egy külön állatfaj, semmihez se hasonlít, az IBM nagyon megfontoltan fejleszgeti, ezt a stabilitást más oprendszer nem tudja szerintem.
--
http://www.javaforum.hu

Amíg használtam értelmes célokra OpenBSD-t, én is olvastam CVS logot, de pár éve ennek, és az idő hiányában leszoktam róla. De nem erről volt szó, hanem valami olyasmiről, mint a FreeBSD reportjai. Szerintem ezek hasznosak, pont azt javítják, amiről beszéltél, hogy mások nem igazán vannak tisztában azzal, hogy mi folyik arrafelé.
És ezek a mások nyilván nem fognak commitlogot olvasni, viszont ehhez hasonló fórumokon szívesen elolvasnák azt a pár bekezdést, ami röviden beszámol az eredményekről (ja, ők meg olvassanak changelogot :).

Tudom, mondjuk ez a rendszer minőségére menés nem teljesen igaz, ott is becsúszhatnak dolgok, bár talán tényleg nem olyan hosszan (és nem release-zel, bár azért azok sem mindig tökéletesek, gondolom olvasod a saját levlistáitokat :), mint a FreeBSD-nél.

Ezek is relatív dolgok, nekem a mai napig van eldugott 5-ös gépem (5.0-RELEASE :), franc se tudja mekkora uptime-mal. Ettől persze nem lesz jó, de konkrétan arra a feladatra pont jó volt, és nem is volt vele gond (nem védem :).

A ZFS nem kötelező, sőt én azt sem mondom, hogy jó. De vannak olyan előnyei az UFS-sel szemben, amelyek miatt jó, ha van. Más értelmes lehetőség meg nincs egyelőre (BSD-n).

Az hogy miert nincs ZFS? Mert inkabb csak hoax van korulotte, mint ertelem, a license elfogadhatatlan es az egesz nagy szar :)

A ZFS nagyon hasznos tud lenni. Sajnálom, hogy nem ismered, mert tiltja a vallásod... :)

Pont 2-3 napja beszeltuk, azt hogy Net/FreeBSD vilagnak goze sincs arrol, hogy mi folyik az OpenBSD haza tajan.

Szoktam olvasgatni OpenBSD-s leírásokat és doksikat. Egyelőre nem tetszik. Ez van.
--
http://www.javaforum.hu

Nem leirasokrol beszelunk. Itt most a fejlesztokrol van szo. A leirasok pedig szerintem szart nem ernek. 90% outdated es nem a megfelelo modon irnak le dolgokat. Ha valamit meg akarsz csinalni akkor olvasd el a manualokat, ne pedig howtokat olvasgass mert abbol:

1. nem fogsz semmit tanulni
2. nagy valoszinuseggel a *rossz* megoldasokat mutatjak be
3. ha megis tanulnal belole akkor rossz berogzodeseid lesznek

Most oszinten te is osszedobtad a leirasod de en mar a powerdns vs. ldap -n kiakadtam. Minek? Ha szepen fogalmazok akkor is brutal overkill az egesz.

De nezzuk elorol. A toor user hasznalata? Jezusom ezt ki mondta? A BSD rendszerek nagy talalmanya...neeee!

Utanna a FreeBSD rendszer *kell* egy sajat kernel config? Minek ? Miert? Mi a baj a GENERIC kernelell? Itt csak atirtad a kernel nevet, de miert? Van ra ertelmes magyarazatod? Nincs. Csak annyi hogy a kezo aki olvasni fogja, teged fog kovetni, rosszul!

Mindent kulon jailbe rakni? Miert? Minek? Azt hiszed hogy ez a biztonsag? Nem. Ez nem az ez csak a sajat magad altal letrehozott extra szopas.

Syslog-ng? Miert? Minek? Tudtad hogy a syslogd(8) is tud masik serverre logolni?

Utanna jon a masik idiotizmus... a sendmail.cf direkt szerkesztese! NEM! Az a file GENERALVA van, NE SZERKEZD! Ird at az m4 filet es generald le ujra.

Tok szep meg jo dolog leirni amit cisnalsz nem is ezzel van a baj, hanem a teljesen rossz praktikak bemutatasaval amit majd masok is atvesznek.

en mar a powerdns vs. ldap kiakadtam. Minek? Ha szepen fogalmazok akkor is brutal overkill az egesz.

Mert így egy helyen, egy adatbázisban van minden. Elég egy helyről menteni a lényeget, könnyű replikálni, ésatöbbi.

A toor user hasznalata? Jezusom ezt ki mondta? A BSD rendszerek nagy talalmanya...neeee!

Idéznék a passwd fájlból: "Bourne-again Superuser". Ez pont arra jó, amit írtam róla. Az, hogy neked személy szerint nem tetszik és ennek hangot adsz, azt figyelembe veszem, de attól még a tények tények maradnak.

Utanna a FreeBSD rendszer *kell* egy sajat kernel config?

Mert úgyis kell egy új kernelt fordítani, az miért ne legyen saját konfig? Az, hogy most még nem került bele semmi plusz paraméter, attól még később kerül majd bele... és ekkor már nem GENERIC a kernel.

Mindent kulon jailbe rakni? Miert? Minek? Azt hiszed hogy ez a biztonsag? Nem. Ez nem az ez csak a sajat magad altal letrehozott extra szopas.

Nem, ez nem extra szopás. Ha frissíteni kell egy programot, akkor klónozom a jail-t, átteszem a szolgáltatást a klónra, frissítem a jail-t, tesztelem és ha jó, akkor visszateszem a szolgáltatást rá és törlöm a klónt (illetve migrálom az adatokat, ha keletkeznek ilyenek). Ez üzembiztonságot ad, szolgáltatásonként meg lehet csinálni, nem okoz leállást ésatöbbi. Persze lehet azt mondani, hogy "extra szopás", de az üzemeltetés mindig is "szopás" volt, most is "szopás" és "szopás" is marad. Ez van.

Syslog-ng? Miert? Minek? Tudtad hogy a syslogd(8) is tud masik serverre logolni?

Azért, mert többet tud. Nem pusztán azért került fel syslog-ng, mert másik szerverre loggolok. Később kap több feladatot is.

Utanna jon a masik idiotizmus... a sendmail.cf direkt szerkesztese! NEM! Az a file GENERALVA van, NE SZERKEZD! Ird at az m4 filet es generald le ujra.

Generálva van, ha generálom. Ha nem, akkor nem. De valóban szebb lenne, ha az mc fájlba írnám és onnan jönne létre a sendmail.cf fájl.

Tok szep meg jo dolog leirni amit cisnalsz nem is ezzel van a baj, hanem a teljesen rossz praktikak bemutatasaval amit majd masok is atvesznek.

A "teljesen rossz praktika" relatív és szubjektív fogalom. Nincs olyan, hogy valami "jó" és másvalami "rossz". Nem fekete és fehér a világ, bár úgy néz ki, hoga a Te a világképed ilyen. Egyszerűbb, szokszor kényelmesebb, de a világ ettől még színes.
--
http://www.javaforum.hu

Ne haragudj thug, de eleg sokmindenben nem ertunk egyet.

Ad1) Ha outdatedek a howto-k miert nem updatelitek oket? Oke, hogy man rulez, de vannak dolgok, amiket jobb egy otmondatos howtobol elolvasni, mint egy bazihosszu manbol kibogaraszni, vagy allandoan a google-t turni azert, hogy a service mondjuk automatikusan induljon, ne kezzel kelljen minden vacakot elinditani reboot utan.

Ad2) Ha a *rossz* megoldasokat mutatjak be a jelenlegi howto-k, nem gondolod, hogy az nem az azt elolvaso ember hibaja, hanem a howto-t IRO embere? Az ilyenekre fel kellene hivni a figyelmet, es surgosen kijavitani/torolni az adott howto-t, nem azt a politikat folytatni, amit te az elozo kommentedben teszel.

- Valoban nem kell mindig sajat kernel, de ha valakinek megis kell, akkor legalabb tudja, hogy hogyan kell csinalni. A topicnyito meg majd beleteszi a wikijebe, hogy ez egy opcionalis lepes.

- A kulon jail, ugyanugy mint a chroot eleg jo modszer az alkalmazasok elszeparalasara, mivel meg a rendszerprogramokban sem illik megbizni, nem egy 3rdparty programban.

- Syslog-ng: Bar ugyse hiszed el, tenyleg sokkal tobbet tud, mint az eredeti syslogd, bar teny es valo, hogy annak a tudasa se keves.

- Leirja, mert o ugy tartja jonak. Vegulis az o rendszere is mukodik, megpedig ugy, ahogy szeretne. Akkor miert lenne rossz? Azert mert nem a BSD-08-02-15-85369 szabvany szerint csinalta meg? Csinaljatok jobb howtokat, mutassatok be, hogyan lehet *jol* megcsinalni ezeket a dolgokat. Mas munkajaba a legkonnyebb belekotni, de ha bevallod, hogy ti csak rosszabb howtokat tudtok felmutatni, akkor talan nem kellene mas felett a palcat torni.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A zfs-sel oltári szopások vannak még FreeBSD-n (lerohadások, a kernel néha "megáll" pihizni, checksum errorok, holott nincsenek, de egyelőre adatot még nem sikerült veszteni vele).
A HEAD (vagy most már trunknak kéne hívni? :) kicsit már jobb állapotban van, bár mintha ahhoz is lennének még be nem került patchek...

Hm... ezt tudom, be is vállalnám, csak ne naponta legyen probléma... :)

Egyébként melyik ág a legfrissebb ilyen szempontból? Jelenleg a RELENG_7-et nézem, abba belekerült egy nagyobb zfs javítás a RELEASE-7 óta, de szerintem is vannak vele gondok még... de csak megjavítják... :)
--
http://www.javaforum.hu


ATTRIBUTES
     See attributes(5) for descriptions of the  following  attri-
     butes:



     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | Availability                | SUNWzfsu                    |
    |_____________________________|_____________________________|
    | Interface Stability         | Evolving                    |
    |_____________________________|_____________________________|

De a diszken lévő adatok formátuma is változik:
http://opensolaris.org/jive/thread.jspa?messageID=262411

Azaz nem stabil, még elég gyakran változik. A megbízhatóság más kérdés.

Solarison a FreeBSD port gyerekbetegségei értelemszerűen nem jelentkeznek. Nekem eddig nem volt vele nagyobb problémám (azon kívül, hogy pld. a kvótakezelés radikális különbözősége miatt nem használom ott, ahol millió plusz user van egyedi kvótákkal).

Hallomásból feltételezel róla rosszat, vagy használod is?

( _Franko_ v | 2008. 08. 24., v – 21:30 )

No, elkészült a levelezés is:

http://wiki.javaforum.hu/confluence-2.8.2/display/FREEBSD/Mail

A tartalomjegyzék:
* 5.2.6.1. Az SMTP szolgáltatás
- 5.2.6.1.1. Az aliases beállítása
- 5.2.6.1.2. LDAP - levelezéshez
- 5.2.6.1.3. LDAP - levelezéshez
* 5.2.6.2. A POP3/IMAP4 szolgáltatás
- 5.2.6.2.1. Az LDAP és a Dovecot
- 5.2.6.2.2. A portforward beállítása
* 5.2.6.3. Biztonságos kapcsolat
- 5.2.6.3.1. Postfix és TLS
- 5.2.6.3.2. Dovecot, POP3S és IMAPS
- 5.2.6.3.3. Levélküldés azonosítással
- 5.2.6.3.4. Szükséges portok
* 5.2.6.4. Spam és vírus szűrés
- 5.2.6.4.1. Postgrey – a szürke zóna
- 5.2.6.4.2. A spam szűrő
- 5.2.6.4.3. A vírus szűrő
* 5.2.6.5. Levelezőlisták
- 5.2.6.5.1. A mailman működése
- 5.2.6.5.2. Új levelezőlista létrehozása
- 5.2.6.5.3. A mailman webes felülete
* 5.2.6.6. Webes levelezés
* 5.2.6.7. Egyéb beállítások
--
http://www.javaforum.hu

A spam szűrést konkrétan mi csinálja? Az amavisd-new-val együtt általában portsból a spamassassin is felkerül, azon viszont érdemes a bayesian szűrést hangolni kicsit, illetve néhány 0 pontos SA paramétert 0.5-re tenni. A spam szűrést ki lehet próbálni gtube-al, ami a spamassassin teszt emailje. A vírusírtót meg az EICAR -al lehet tesztelni. Ezeket egyébként nem árt kipróbálni, mert később jöhet meglepi. :)

( Dacr (nem ellenőrzött) | 2008. 08. 25., h – 13:16 )

Jó kis leírás, kedvet kaptam a BSD megismeréséhez! Köszönöm!

( esikgabi | 2008. 08. 28., cs – 01:19 )

Hello

Nagyon jó kis leírás az egész, és ezen felbuzdulva kedvet is kaptam hozzá hogy pár dolgot kipróbáljak belőle az itthoni kis házi freebsd szerveremen.
Elkezdtem újraforgatni az egész rendszert sorban úgy ahogy le volt irva :
cvsup -al frissítettem a forrásokat
meg csináltam a saját kernelemet
aztán szép sorban
time make buildworld , time make buildkernel, /etc/rc.d/hostid start, mount -u /, cd /usr/src ,time make installworld, rm -rf /tmp/install.PNth69uR, make installkernel, kldxref /boot/kernel, exit

restart után szépen fel is állt a rendszer és az eredmény:
ibm# uname -a
FreeBSD ibm 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Wed Aug 27 19:39:56 CEST 2008 esikgabi@ibm:/usr/obj/usr/src/sys/ibm i386

szépen frissítette is FreeBSD 7.0 -Current -ről

a meglévő szolgáltatások szépen mennek és működnek is viszont valami nincs rendjén a rendszernek,
semmit nem tudok frissíteni, ugyanis a gcc nem tud semmit lefordítani
egy sima hello -t kiiro c file-ra is ezt irja ki:
ibm# gcc teszt.c
gcc: Internal error: Segmentation fault: 11 (program ld)
Please submit a full bug report.
See for instructions.

a dmesg parancs hatására megjelenő kép tele van ilyen sorokkal:
pid 1032 (ld), uid 0: exited on signal 11 (core dumped)
pid 2228 (ld), uid 0: exited on signal 11 (core dumped)
pid 2279 (ld), uid 0: exited on signal 11 (core dumped)
pid 2285 (ld), uid 0: exited on signal 11 (core dumped)

valamint az itt szereplő alkalmazás (ld) elinditásakor ezt kapom:
ibm# ld
Segmentation fault (core dumped)

Keresgéltem a neten de nem találtam semmi megoldást a problémámra, így dondoltam leírom ide, valamenynire csak kapcsolódik ehhez a témához, hisz ebből indultam ki, lehet valamit én csináltam rosszul nemtudom.
Persze mivel én nem használok zfs-t így azon részeket kihagytam, de ahogy a handbook -ot is néztem ugyhiszem a kellő dolgokat megcsináltam.

Remélem valaki tud majd valami megoldást ajánlani a problémámra.
Köszi szépen előre is!

üdv:
esikgabi

jelenleg a RELENG_7 a 7.1-PRERELEASE-t jelenti, de ha rosszul tudom,
akkor Zahy kollega kijavit

ha a 7.0-ahoz csak a biztonsagi javitasokat akarod lerantani a csup-pal,
akkor a supfile-ba RELENG_7_0 kerul
(ha 6.3-as a rendszer, akkor RELENG_6_3)

bovebb info itt

/* bocs az esetleges helyesirasi hidakert */

Hát akkor valszeg ez lesz a problémám oka.
Most megpróbálom ujra felépíteni az egész rendszeremet, minden fontos config-file-rol csináltam mentést, ugyhogy a beállításokkal már nem kell sokat kisérletezni.
A most frissen rakott rendszerem ujbol megpróbálom frissiteni, már csak azért is!
A rendszerből vett stable-supfile-t szerkesztettem át az alábbi értékekkel:
*default host=cvsup.hu.FreeBSD.org
*default release=cvs tag=RELENG_7_0

A többit úgy hagytam ahogy volt.
Remélem a RELENG_7_0 már tényleg a 7.0-STABLE biztonsági frissitéseit fogja csak letölteni

Addig nem ís telepitek rá semmi egyebet míg ezt nem sikerül úgy megcsinálni hogy jó legyen.

Safe mode-ban vagy miben kell installworld-ot csinalni, az installkernelt pedig lehet normal userlandbol. Igazából valszin az történik, hogy a libc vagy hasonló védett könyvtár nem frissült és pedig a gcc erősen próbál hivatkozni valamilyenúj hívásra.

Próbáld meg az installworld-ot úgy hogy a 7.0ás kernelt bootolod, ha még megvan. A bootloaderben ehhez egy egészen ügyes parancssoros cucc van.

( agolon | 2010. 08. 26., cs – 14:01 )

Hogy stílszerűek legyünk, ez egy elég frankó leírás. Köszi, segített pár dologban.
--
2e845cb4c3a5b5bd6508455b1739a8a2