[dudancs]

Egy kérdésem volna hozzátok. A squid kérdésekben már feltettem kérdésem de
gondoltam ide is beteszem hátha szerencsével járok. Tehát a kérdés:
van egy hálózat diákgépekkel + tanárgépekkel. Azt szeretném megoldani, hogy
egy txt-ben legyenek felsorolva azok az ip-k amelyek netezhetnek.

        "  acl MEHET src "ipk.txt"  " ez mind szép és jó tehát megy.

De amint változtattom a txt-t vagyis kiveszek belõle egy IP-t olyan mintha mise
történt volna. Valahogyan megoldható a problémám? Jaj még annyi, hogy SquidNT.
De ahogy elnéztem az acl szabályzat ugyan az. Egy ötletem volt még. írni kellene
egy helpert ami vissza ad OK-t vagy ERR-t external_acl_type-ban. Csak nem tudom,
hogy mi szerint lehetne ellenörizni a helperen belül.  :confused:  Bocsi ha nem ide
tartozik de már el vagyok keseredve nagyon .

[bogdan]

ujra is inditottad a squid-et? mert altalaban a programok ujrainditaskor olvassak be a dolgaikat, igy a menet kozbeni valtoztatas mit sem er ujrainditas nelkul..

[dudancs]

Idézet: bogdan - Dátum: 2008. jún. 23., hétfõ - 8:26

ujra is inditottad a squid-et? mert altalaban a programok ujrainditaskor olvassak be a dolgaikat, igy a menet kozbeni valtoztatas mit sem er ujrainditas nelkul..

Bocsi ezt elfelejtettem írni. Ha újraindítom akkor természetesen jó megint minden.
De úgye azért mondjuk egy általános iskolában nem szívesen engedném meg hogy
bárki csak úgy újra indíthassa. Ezért gondolkoztam hogy talán kellene egy
external_acl_type-t létrehozni amiben egy helper megmondaná hogy mehet e az ip vagy sem.
Ilyesmire gondolok: Squid delphi
De mivel nem tudom hogy mit mivel kell benne ellenöriztettni ezért nem igaazán tudom megoldani.
Nem a delphi kérdéses hanem az hogy honnan veszem az éppen aktuális IP-t (kérést küldõ kliensét).

[bogdan]

szerintem mindenkeppen szukseg lesz az ujrainditasra, vagy legalabb a conf file beolvasasara.
egyebkent nem ertem a "barki"-t! azt a txt-t, ami megmondja a szabalyt barki irhatja?? na ugye! hat aki azt irhatja, annak adj jogot (sudo) a squid ujrainditasara. en nem latok ebben akkora kockazatot.

[dudancs]

Idézet: bogdan - Dátum: 2008. jún. 23., hétfõ - 9:03

szerintem mindenkeppen szukseg lesz az ujrainditasra, vagy legalabb a conf file beolvasasara.
egyebkent nem ertem a "barki"-t! azt a txt-t, ami megmondja a szabalyt barki irhatja?? na ugye! hat aki azt irhatja, annak adj jogot (sudo) a squid ujrainditasara. en nem latok ebben akkora kockazatot.

Ebben igazad van. De sajna itt van egy kis csavar a dologban. A Squid amit én használok az egy
windows-on futó verzió. Tehát szolgáltatásként fut. Most hogy egy kicsit utána néztem nagy
valószínûséggel probálkozni fogok még ezzel az external_acl_type-al. De örülnék bármiféle
segítségnek. De ha nagyon nem megy akkor marad a Debian telpítés. Elökerülnek a fõsulis cuccok.

[bogdan]

nos..
1) attol meg, hogy windows-on fut meg lehet jogosultsagokat allitani hozza, hogy ki indithatja ujra!
2) ha windows-on fut mit keres ez itt, ebben a topicban? ez itten a "mas vilag", azaz a windowst nem igazan kedvelok tarsasaga.. 

[dudancs]

Idézet: bogdan - Dátum: 2008. jún. 23., hétfõ - 9:29

nos..
1) attol meg, hogy windows-on fut meg lehet jogosultsagokat allitani hozza, hogy ki indithatja ujra!
2) ha windows-on fut mit keres ez itt, ebben a topicban? ez itten a "mas vilag", azaz a windowst nem igazan kedvelok tarsasaga.. 

Igazad van minde kettõben. De elegánsabb lenne ha mondjuk csak egy txt-file-t kellene módosítani
mert azt már mondjuk delphiben írt progival is megoldható. A kérdést pedig azért itt tettem
fel mert szerintem itt többen értenek a Squidhoz mint a Microsoft részben... a válaszokat.

[pike.killer]

Idézet: dudancs - Dátum: 2008. jún. 23., hétfõ - 10:34

Igazad van minde kettõben. De elegánsabb lenne ha mondjuk csak egy txt-file-t kellene módosítani
mert azt már mondjuk delphiben írt progival is megoldható. A kérdést pedig azért itt tettem
fel mert szerintem itt többen értenek a Squidhoz mint a Microsoft részben...   a válaszokat.

Egyszeru mint az 1x1 nem kell mast csinalni Linux eseteben mind mondjuk egy cron bejegyzes segitsegevel minden percben ujra olvastatod a config filet. Itt egy bug van hogy a modositastol max 59mp kell varni amig eletbe lep.

[bogdan]

linux eseteben mar zaporoztak volna a megoldasi javaslatok. csakhogy itt windows-rol van szo!

[kroozo]

Idézet: bogdan - Dátum: 2008. jún. 27., péntek - 10:55

linux eseteben mar zaporoztak volna a megoldasi javaslatok. csakhogy itt windows-rol van szo!

Hat, speciel scheduler, az van windows alatt is

Squidnal egyebkent nem tudom hogy van, rendes unixos daemonok szoktak ugye olyat csinalni, hogy valami signallal ha megkinalod oket, akkor ujraolvassak a konfigot. Mondjuk nem tudom, windows alatt ez a signalosdi hogy van, gondolom nem POSIX.

[bogdan]

speciel epp, hogy POSIX!
de hogy hogyan van.... azt a joeg tudja! (no meg a megfelelo forum kozonsege, ami ugye nem ez )

[kroozo]

Idézet: bogdan - Dátum: 2008. jún. 27., péntek - 12:07

speciel epp, hogy POSIX!
de hogy hogyan van.... azt a joeg tudja! (no meg a megfelelo forum kozonsege, ami ugye nem ez )

Hmm... Most nezegetem, de nem talalok a rendes doksit hozza Mindenesetre en ugy emlekszem, hogy nem igazan ugy mukodott a processzkezeles, mint ahogy posixos oprendszerekben, meg mintha valami perl doksiban olvastam volna olyat, hogy a windowson a perl hazudja be az ilyesmit valahogy, amikor kezelni akarod oket.

De lehet, hogy hulyeseg, meg rosszul emlekszem

[bogdan]

az tuti, hogy POSIX kompatibilis (http://en.wikipedia.org/wiki/POSIX), igaz a teljes kompatibilitashoz kulon package kell meg.
de ha az is, agyuval verebre kategoria, ha posix hivasokon keresztul akar az ember ilyen kerdest megoldani: bizonyara a windows services is tud nativan olyat, amirol beszelunk...

[Mono]

Sziasztok!

Van egy kisebb gondom, több topikban is elfért volna, de talán ez a legmegfelelõbb.
Adott egy céges levelezõ szerver, hardveres RAID5 tömb, Courier-IMAP a MUA, kb. 50GB az összes felhasználó szerveren levõ levelezése. Napi mentés készül minden hajnalban. Vezetõség sokat utazik, nyílnak külföldi leányvállalatok is. Eddig úgy történt a mentés, hogy leállítottam az SMTP-be ágyazott víruskeresõt, valamint magát az IMAP démont, ezzel gyakorlatilag megakadályoztam azt, hogy az éppen mentés alatt levõ könyvtárak tartalma megváltozhasson. Felhasználók nem tudták olvasott/nem olvasott státuszát változtatni a leveleiknek, nem tudták törölni õket, más mappákba mozgatni a leveleiket a mentés alatt. SMTP fogadta a kintrõl érkezõ leveleket, de mivel nem tudta átadni a szerveren futó, SMTP-be integrált víruskeresõnek, mert az szintén le volt állítva, queue-ban maradt. Amikor a mentés lezajlott, indítottam az IMAP démont, valamint a víruskeresõt, így az SMTP queue ki tudott ürülni, user megkapta a levelét, illetve lehetõség nyílt a postafiókot használni.
A mentés két lépcsõben zajlik, elõször csak egy-egy tar készül a felhasználók mailboxáról, erre az idõre vannak csak leállítva az említett szolgáltatások. A gzip tömörítés pedig már a tar fájlokról készül. Azaz szerintem ennél rövidebb ideig nem állhatnak a szolgáltatások, de most már ez is gond. Mindig van olyan felhasználó a világ valamely pontján, aki éppen akkor akar marhára levelezni, amikor a mentés zajlik (kb. 1...1,5 óra ideig tart a tarolás).

Az egy szerveres megoldást megtartanám, ha mód van rá. Mit ajánlotok, hogyan tudnám úgy menteni a dolgokat, hogy a mentés biztonságos legyen, de közben mûködjenek a szolgáltatások

Nem tartottam szerencsésnek, ha a tarolás közben változhat az a könyvtár tartalma, melyrõl készül a tar. Mit tudtok errõl, lehet ebbõl gond, vagy ez valami kernel/op.rendszer, stb. módon már kivédett dolog :confused:
Kérdezhetném úgy is, hogy (mert vagy ugyanerrõl van szó, vagy akár módosíthatom is a szkriptet) ha másolok egy könyvtárat, melynek tartalma változik, milyen eredményre számíthatok Ha csak azok másolódnak át, mely a másolás megkezdésekori állapot volt, nekem az már tökéletes lenne, kérdés, mennyire eredményez ez stabil eredményt, használható lehet-e egy ilyen backup, ha szükség van rá

[kroozo]

Idézet: Mono - Dátum: 2008. júl. 2., szerda - 8:52

Sziasztok!

Van egy kisebb gondom, több topikban is elfért volna, de talán ez a legmegfelelõbb.
Adott egy céges levelezõ szerver, hardveres RAID5 tömb, Courier-IMAP a MUA, kb. 50GB az összes felhasználó szerveren levõ levelezése. Napi mentés készül minden hajnalban. Vezetõség sokat utazik, nyílnak külföldi leányvállalatok is. Eddig úgy történt a mentés, hogy leállítottam az SMTP-be ágyazott víruskeresõt, valamint magát az IMAP démont, ezzel gyakorlatilag megakadályoztam azt, hogy az éppen mentés alatt levõ könyvtárak tartalma megváltozhasson. Felhasználók nem tudták olvasott/nem olvasott státuszát változtatni a leveleiknek, nem tudták törölni õket, más mappákba mozgatni a leveleiket a mentés alatt. SMTP fogadta a kintrõl érkezõ leveleket, de mivel nem tudta átadni a szerveren futó, SMTP-be integrált víruskeresõnek, mert az szintén le volt állítva, queue-ban maradt. Amikor a mentés lezajlott, indítottam az IMAP démont, valamint a víruskeresõt, így az SMTP queue ki tudott ürülni, user megkapta a levelét, illetve lehetõség nyílt a postafiókot használni.
A mentés két lépcsõben zajlik, elõször csak egy-egy tar készül a felhasználók mailboxáról, erre az idõre vannak csak leállítva az említett szolgáltatások. A gzip tömörítés pedig már a tar fájlokról készül. Azaz szerintem ennél rövidebb ideig nem állhatnak a szolgáltatások, de most már ez is gond. Mindig van olyan felhasználó a világ valamely pontján, aki éppen akkor akar marhára levelezni, amikor a mentés zajlik (kb. 1...1,5 óra ideig tart a tarolás).

Az egy szerveres megoldást megtartanám, ha mód van rá. Mit ajánlotok, hogyan tudnám úgy menteni a dolgokat, hogy a mentés biztonságos legyen, de közben mûködjenek a szolgáltatások

Nem tartottam szerencsésnek, ha a tarolás közben változhat az a könyvtár tartalma, melyrõl készül a tar. Mit tudtok errõl, lehet ebbõl gond, vagy ez valami kernel/op.rendszer, stb. módon már kivédett dolog :confused:
Kérdezhetném úgy is, hogy (mert vagy ugyanerrõl van szó, vagy akár módosíthatom is a szkriptet) ha másolok egy könyvtárat, melynek tartalma változik, milyen eredményre számíthatok Ha csak azok másolódnak át, mely a másolás megkezdésekori állapot volt, nekem az már tökéletes lenne, kérdés, mennyire eredményez ez stabil eredményt, használható lehet-e egy ilyen backup, ha szükség van rá

Elso bliccre siman azt mondanam, hogy aki ir, az lockolni fogja a filet, ergo a tar vagy perm deniedet mond, vagy var, mig fel nem oldodik a lock (ez a valoszinubb), szoval ez nem kene gond legyen.

[bogdan]

a unix rendszereket nem nagyon zavarja az, hogy ki nyul bele kozben! ki lehet probalni: elinditasz egy file lejatszast (mondjuk film), kozben torlod a file-t, sot a konyvtarat is, ahol volt. a lejatszas megy tovabb rendesen, mikozben mas shell-bol meg csak a konyvtar sem latszik. ha leallitod, akor a nem letezo konyvtarban allsz, es amig nem adsz ki egy "cd .."-ot, addig panaszkodik egy kicsit. de tok stabil!

hogy on legyek: a volt munkahelyemen tar-ral mentettunk szalagra (most mar winchesterre), de semmi kozbeni leallas nem volt. (nem is lehetett volna, mert ugyanugy 24 oraban birizgaljak a felhasznalok, es raadasul sok oran keresztul futott. de soha semmilyen baj nem volt ezzel. eveken keresztul, most mar inkabb egy evtizede lehet igy az a rendszer. szoval nem kell izgulni, jol lesz kimentve.

[SFIJ]

Idézet: kroozo - Dátum: 2008. júl. 2., szerda - 9:02

Elso bliccre siman azt mondanam, hogy aki ir, az lockolni fogja a filet, ergo a tar vagy perm deniedet mond, vagy var, mig fel nem oldodik a lock (ez a valoszinubb), szoval ez nem kene gond legyen.

ez nem biztos! unixnal van az flock api, ha azt hasznalja minden szoffer aki az adott fajlt hasznalja akkor rendes lockolas van, deha jon egy n+1 szoft ami nem hasznalja az flock api-t az siman alavaghat a lockolasi tancnak.

[kroozo]

Idézet: SFIJ - Dátum: 2008. júl. 2., szerda - 11:52

ez nem biztos! unixnal van az flock api, ha azt hasznalja minden szoffer aki az adott fajlt hasznalja akkor rendes lockolas van, deha jon egy n+1 szoft ami nem hasznalja az flock api-t az siman alavaghat a lockolasi tancnak.

Szerintem a legtobb dolog azert hasznalja. Nem emlekszem olyanra, hogy ilyesmi miatt valaha bajom lett volna

De ha nem is, akkor is az van, hogy max az epp beeso levelet szarul teszed el, es majd csak a holnapi backupba lesz benne.

[Mono]

Uraim, köszönöm a válaszokat, eléggé meg lettem nyugtatva

Én is így gondolkozom egyébiránt:

Idézet

De ha nem is, akkor is az van, hogy max az epp beeso levelet szarul teszed el, es majd csak a holnapi backupba lesz benne.

Ezer köszönet!

[bogdan]

nem lesz rosszul elteve az sem. vagy ott lesz, vagy nem lesz ott.