Linux-haladó

Sziasztok,
Gondoltam lecserelem mod-php5ot fcgire. Bizonyos vhostok mentek szepen, bizonyos vhostokra meg forbidden-t dobott.
Csinaltam most egy olyan configot, hogy mod-php5 is van es fcgi is, beraktam a kovetkezo sorokat abba a vhostba ami forbiddeneket dobott:
IPCConnectTimeout 20
AddHandler fcgid-script .php
FCGIWrapper /usr/bin/php5-cgi .php
AddHandler fcgid-script .html
FCGIWrapper /usr/bin/php5-cgi .html

Nem valtozott a helyzet.
Hiaba rakom debugra apache logot, semmi nicnsen benne. A jol mukodo vhost konyvtarjat kitoroltem kezzel csinaltam egy ujat,es valami alap phpt beleraktam, es mukodik, ha ezt megcsinalom a nem mukodovel, ugyan ugy forbiddent dob, csinaltam egy vadi uj vhostot, mas nevvel,mas konyvtarral, es nem megy, belemasolom a mukodo vhost docrootjat,akkor ott mar nem mukodik. Apache error logban nincsen "[notice] mod_fcgid: call", mintha apache eldobna.
Egyszeruen nem tudom megfogni, hogy mivel lehet a gond, sajnos osszetett szerverrol van szo, igy konnyen lehet valami specialis beallitas, de amig nem tudom egy dologhoz kotni, eselyet sem latom, hogy rajovok. Annyira nem fontos, letettem mar fcgirol, viszont a problema megoldasa foglalkoztat.
Valakinek esetleg 5lete?

Lécci segítsetek, mert valamit nagyon benéztem és nem boldogulok...

Debian lenny, 2.6.26, xen 3.2-es gép egyik ethernet lába eth0, néz az internet felé. Másik ethernet lába eth1, a belső hálózat felé, a harmadig ethernet eth2 pedig össze van bridge-lve a rajta futó guest-tel. Az egyszerűsítés kedvéért a belső hálózati láb és ez a harmadik láb össze van kötve keresztkábellel.

Az elképzelt setup az lenne, hogyha a xen guest akar letölteni, akkor a kifelé menő forgalma a bridge-n keresztül kimegy eth2-őn, majd eth1-en visszajön a xen hostba, ott masqolódik és úgy megy ki a netre. Visszafelé értelemszerűen az eth0-n bejön a hostba, et1-en kimegy a helyi hálózatra, majd eth2-n visszajön a bridge-n keresztül a guestbe, közben megoldódik a masqolás is.

A /proc/sys/net/ipv4/ip_forward 1-re van állítva. Az iptables:
iptables -L -t nat -n -v
Chain PREROUTING (policy ACCEPT 107 packets, 11457 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 821 packets, 55991 bytes)
pkts bytes target prot opt in out source destination
3 984 MASQUERADE all -- * * 192.168.253.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 736 packets, 49187 bytes)
pkts bytes target prot opt in out source destination

és
iptables -L -n -v
Chain INPUT (policy ACCEPT 100K packets, 8021K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 186K packets, 278M bytes)
pkts bytes target prot opt in out source destination
93358 4886K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif4.0

Chain OUTPUT (policy ACCEPT 13302 packets, 271M bytes)
pkts bytes target prot opt in out source destination

Ha tcpdumpolom a forgalmat az interfészeken, jónak tűnik. Viszont kifelé masqolás nélkül megy ki a forgalom, a 192.168 kezdetű címet látom a távoli célgép kártyáját dumpolva.

Amikor a xen hoston futó web szerverről akarok teszt adatot letölteni, az megy.

Miért nem masqol nekem???

Üdv!

Postfix kérdés. (debian)
Adottak az alábbi paraméterek:

smtpd_client_connection_rate_limit =100 (default: no limit)
smtpd_client_message_rate_limit = 500 (default: no limit)
smtpd_client_recipient_rate_limit = 100 (default: no limit)
( a default_destination_recipient_limit alapon van: 50 )

és adott ez:
smtpd_client_event_limit_exceptions (ami alapban $mynetworks)
smtpd_client_connection_limit_exceptions (ami alapban $mynetworks)

Na most én szeretném ha a mynetworks -ben lévőekre IS vonatkozna a limit, mert
- sajnos - vannak a hálón belül is zombivá vált/válható gépek.

Kérdés:
a fenti limitek nem túl erősek? (conn rate limit 100, message rate limit 500, illetve a recipient rate limit 100,
amikor a anvil_rate_time_unit alapon, azaz 60s -on van. (Kb 1500 email fiók, általános használat)

illetve az exceptions -nak milyen értéket kell adni, hogy ne legyen exceptions :)

Hello

Milyen eszközzel lehet kideríteni, hogy több virtualhostot kiszolgáló apache webserveren melyik oldal eszi a legtöbb erőforrást? Melyiket látogatják legtöbben?

Céges szerver ~2TB adatáról szeretnék biztonsági mentést DVD-re.

Végigolvastam több backup témájú fórumot, de nemigen találtam az enyémhez hasonló problémát, illetve arra megoldást. Előre bocsátom, hogy nem vagyok teljesen képben a backup elvekkel és gyakorlattal, így lehet, hogy a spanyolviaszt próbálom feltalálni, ezt kéretik elnézni.

Tehát adott egy kisirodai szerver ~2TB-nyi samba tárterülettel valamint 2db DVD íróval. Ezeket szeretném biztonsági mentésre felhasználni. (nézegettem használt 12/24-es DAT meghajtókat, de kifejthetné valaki, hogy jobb-e nekem az, és ha igen, miért)
Az általam elképzelt elv:
- minden éjszakára kap a gép 2db üres lemezt, amit éjszaka teleírhat
- először természetesen a jelenleg meglevő adatoknak kellene rákerülni szép sorban a lemezekre
- a későbbiekben inkrementális mentés készülne a napi friss adatokból
- de, hogy ne bízzuk az adatokat 1-1db DVD lemez élettartamára, ezért az inkrementális mentés mellé, a maradék területre mindig felkerülhetne a legrégebben mentett adatok másodlagos mentése
- persze kéne egy adatbázis, ami mindezt nyilvántartja és esetleg DVD lemez szintjén közli, hogy mi az, amit már ki lehet dobni (a rajta levő adatok már elavultak, és/vagy több, mint 2 másolat van belőlük)
- természetesen szükség esetén képes legyen a rendszert a lemezek bekéregetésével automatikusan visszaállítani

A rengeteg kész, opensource backup alkalmazás között létezik, ami ezt tudja - és valaki már ki is próbálta? Vagy scripteljem le magam?

Várnék némi segítséget, javaslatot. Köszi

ps.: Ja, a szerveren Gentoo van.

Hi!

Olyan gondom volna, hogy fel kellene toltenem nehany 100 felhasznalot SaMBa+LDAP-ba, de az ekezetes nevek kodolasa rossz: "Tamás" Tamás helyett, stb (ebben az a szep, ha valakinek a bongeszoje meg ezen is csavar egyet:)
A felhasznalok felvetelet az smbldap-useradd-dal vegzem.
Van valakinek otlete, mit lehet ezzel kezdeni? Legrosszabb esetben ekezetlenitem a neveket, bar annak is utana kell akkor keresnem, ezt mivel tudom megtenni.

Elore is kosz.

Sziasztok,

Meg tudja mondani valaki mire való a /proc/sys/kernel/hung_task_timeout_secs ?

Mi történik ilyenkor?


Aug 2 02:05:04 localhost kernel: [10057716.044272] INFO: task md1_resync:512 blocked for more than 120 seconds.
Aug 2 02:05:04 localhost kernel: [10057716.044318] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 2 02:05:04 localhost kernel: [10057716.044346] md1_resync D e0e84a9c 0 512 2
Aug 2 02:05:04 localhost kernel: [10057716.044372] dcfe71c0 00000046 312e3333 e0e84a9c 0023b7b9 dcfe734c c13c9fa0 00000000
Aug 2 02:05:04 localhost kernel: [10057716.044419] 36616336 00000003 000009ce 00000000 dc7b800c dc041e00 dbc05f8c dc0c4de8
Aug 2 02:05:04 localhost kernel: [10057716.044465] dc7b800c dc041e00 dbc05f8c dc0c4de8 de85d6ad de862e84 de862e5f dc7b800c
Aug 2 02:05:04 localhost kernel: [10057716.044514] Call Trace:
Aug 2 02:05:04 localhost kernel: [10057716.044644] [] md_do_sync+0x238/0xa84 [md_mod]
Aug 2 02:05:04 localhost kernel: [10057716.044753] [] getnstimeofday+0x37/0xbc
Aug 2 02:05:04 localhost kernel: [10057716.044810] [] enqueue_hrtimer+0xc9/0xd4
Aug 2 02:05:04 localhost kernel: [10057716.044854] [] hrtimer_start+0xf7/0x110
Aug 2 02:05:04 localhost kernel: [10057716.046267] [] hrtick_set+0x8f/0xd8
Aug 2 02:05:04 localhost kernel: [10057716.046320] [] autoremove_wake_function+0x0/0x2d
Aug 2 02:05:04 localhost kernel: [10057716.046363] [] md_thread+0x0/0xcd [md_mod]
Aug 2 02:05:04 localhost kernel: [10057716.046401] [] md_thread+0xb7/0xcd [md_mod]
Aug 2 02:05:04 localhost kernel: [10057716.046436] [] complete+0x28/0x36
Aug 2 02:05:04 localhost kernel: [10057716.046477] [] md_thread+0x0/0xcd [md_mod]
Aug 2 02:05:04 localhost kernel: [10057716.046507] [] kthread+0x38/0x5d
Aug 2 02:05:04 localhost kernel: [10057716.046528] [] kthread+0x0/0x5d
Aug 2 02:05:04 localhost kernel: [10057716.046554] [] kernel_thread_helper+0x7/0x10
Aug 2 02:05:04 localhost kernel: [10057716.046606] =======================


Diagnózis: a hálózati kapcsolatok távolról DNAT-tal vagy VPN kapcsolaton keresztül akadoznak, megállnak. MTU mindenhol jó, mégis az a tünet tapasztalható, mintha rossz érték lenne.

Megoldás röviden: a belső hálózaton a csomagok MTU-nál nagyobb méretekben is utazhatnak, mivel a hálókártya képes kezelni az ún TSO/GSO opcióval. Viszont a VPN kapcsolaton ez nem megy át, ha a VPN kliens egy alhálózaton van a másik géppel. Ilyen esetben ki kell kapcsolni a TSO/GSO-t, így:

# ethtool -K eth0 tso off

ekkor a csomagoknak maximum MTU-nyi mérete lehet.

Hálózati kommunkációs problémával kapcsolatban nyomozok, és a tcpdump ezt a kimenetet generálta egy adott, 1500 byte-nál biztosan nagyobb HTTP (kérés és) válasz küldésekor (magyarázat a log alatt):

00. 15:18:20.456694 IP client.54491 > server.www: S 3231913881:3231913881(0) win 8192 <mss 1360,nop,wscale 2,nop,nop,sackOK>
01. 15:18:20.472053 IP server.www > client.54491: S 2863046274:2863046274(0) ack 3231913882 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
02. 15:18:20.479738 IP client.54491 > server.www: . ack 1 win 16660
03. 15:18:20.481257 IP client.54491 > server.www: P 1:564(563) ack 1 win 16660
04. 15:18:20.481282 IP server.www > client.54491: . ack 564 win 109
05. 15:18:20.503103 IP server.www > client.54491: . 1:2713(2712) ack 564 win 109

06. 15:18:23.500977 IP server.www > client.54491: . 1:1357(1356) ack 564 win 109
07. 15:18:23.750394 IP client.54491 > server.www: . ack 1357 win 16321
08. 15:18:23.750409 IP server.www > client.54491: . 2713:4069(1356) ack 564 win 109
09. 15:18:23.750413 IP server.www > client.54491: P 4069:4892(823) ack 564 win 109
10. 15:18:23.797477 IP client.54491 > server.www: . ack 1357 win 16321 <nop,nop,sack 1 {2713:4069}>
11. 15:18:23.814654 IP client.54491 > server.www: . ack 1357 win 16321 <nop,nop,sack 1 {2713:4892}>

12. 15:18:29.749315 IP server.www > client.54491: . 1357:2713(1356) ack 564 win 109
13. 15:18:29.796617 IP client.54491 > server.www: . ack 4892 win 16660
14. 15:18:29.823615 IP client.54491 > server.www: P 564:1242(678) ack 4892 win 16660
15. 15:18:29.845470 IP server.www > client.54491: P 4892:5117(225) ack 1242 win 131
16. 15:18:30.074072 IP client.54491 > server.www: . ack 5117 win 16603

17. 15:18:44.846259 IP server.www > client.54491: F 5117:5117(0) ack 1242 win 131
18. 15:18:44.869317 IP client.54491 > server.www: . ack 5118 win 16603
19. 15:18:44.976057 IP client.54491 > server.www: F 1242:1242(0) ack 5118 win 16603
20. 15:18:44.976069 IP server.www > client.54491: . ack 1243 win 131

Amit látok, persze lehetséges, hogy rosszul értelmezem a látottakat:
00-02: felépül a TCP kapcsolat a 80-as porton
03-04: HTTP GET parancsot küld a kliens
05: számomra teljesen érthetelen módon a webszerver egy 2712 byte méretű csomagot küld (holott előtte mss-nek 1360 és 1460-at beszéltek meg)
ezek után vár három másodpercet (gondolom valamilyen csomagvisszaigazolási limit), majd
06: újraküldi az első adatcsomagot immár kisebb, 1356-os mérettel
07-11: de a második csomag kimarad a láncból! ha megfigyelitek 1357-2713 byte-ig a csomagot még nem küldte el! gondolom ezért van az, hogy most vár 6 másodpercet, és
12: elküldi a kimaradt 2. sorszámú csomagot
13-16: maradék csomagok, adatátvitel vége
17-20: nincs már szükség a HTTP kapcsolatra, bontanak a felek

Ami tény:
server# ifconfig eth0 | grep MTU
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

A tcpdumpot a webszerveren futtattam.

A szerver ubuntu 8.04 lts.

A kliens és a szerver DSL kapcsolat mögött ül, mindkettő 1452-es MTU mellett.

A kliens egy VPN kapcsolaton (pptpd) keresztül éri el a webszervert az alábbi IP kofigurációban (példa):
szerver ip: 10.1.0.20 netmaszk: /16
kliens ip: 10.2.0.10 netmaszk: /16

A probléma a következő azon kívül, hogy minden egyes kapcsolat, ami meghaladja az MTU-t legalább 3 másodpercig megakad:
Inkrementálódnak a várakozási idők, azaz először 3, majd 6, és így tovább egyre több időt várakozik a csomagok újraküldése között,
és *nem* *jegyzi* *meg* az átvihető csomag méretét! Továbbra is próbálkozik majd a 2712 byte-ot küldeni ill. láttam
már 2720-as méretű csomagokat is (gyanúsan 1360*2).

A probléma nem csak a webes kapcsolatot érinti, hanem pl. az SSH-t is majd' mindegyik belső szerver irányába. Belső hálózaton minden tökéletes.
Kivétel: van két szerver, amit korábban telepített egy rendszergazda, azok tökéletesen működnek, ott meg sem próbál MTU-nál nagyobb csomagot küldeni.

Próbáltam már VPN nélkül is, iptables-sel DNATolva a gateway-től a webszerverig, ugyanaz a jelenség.

Mit lehet tenni? MTU-kat már állítgattam, de számomra mindenhol normálisnak tűnik.
Kérem valaki világosítson fel mit csinálok rosszul!
Összehasonlítanám a jó és a rossz szerverek sysclt-jét, de nem tudom mit keressek... :\

Hali.

Egy 7.2-es FreeBSD-re ezjail segitsegevel telepitek samba+ldap-os PDC-t.
Egyetlen egy gondom van, megpedig a felhasznalo zarolassal.
Mukodni mukodik az is igazabol, csa hibasan. A jelenseg a kovetkezo(miutan ketszer rossz jelszoval probaltam belepni, egy a tartomanyba beleptetett geprol.):
[root@samba ~]# pdbedit -lv username
...
Password last set: Fri, 31 Jul 2009 13:53:51 CEST
Password can change: Fri, 31 Jul 2009 13:53:51 CEST
Password must change: never
Last bad password : Mon, 18 Jun 984828198 13:40:49 CET
Bad password count : 2
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Mint lathato, a "Last bad password" timestamp-je egy kicsit erdekes erteket vesz fel :)
A limit mosr 3ra van allitva, es ha megeszer elrontom a jelszot zarol is meg minden.
Kezzel tudom unlockolni a usert, ekkor a Last bad password 0-ra allitodik, a szamlaloval egyutt.
Gondolom mukodne az automatikus unlock is, hogyha nem jovobeli idopont lenne bellitva last bad password-nek.

Kerestem neten megoldast a problemara, de vagy nem megfelelo keresoszavakkal, vagy meg senkinek nem volt ilyen gondja soha :)
Ha valakinek van tippje, hogy mi lehet a gond, vagy megoldas ne fogja vissza magat :)

ELore is, koszi.

Udv!

Adott nekem egy XEN-el virtualizált szerver. A domU-k route-olva vannak, port forwarding segítségével szolgálnak ki bizonyos szolgáltatásokat.

A rajtuk futó webszervereket bárhonnan elérem, kivéve önmagukat. Szoval bárhol beírom a fizikai gép hostnevét/IP-jét, gyönyörűen megnyitja az oldalt, kivéve ha ezt azon a gépen teszem, amelyik végülis kiszolgálja a webet. Egyszerűen timeout.

Kézzel is megírtam már a szabályokat, azóta tettem fel egy shorewall-t, de a probléma marad.

A kérdésem, hogy én néztem el valamit, és tényleg eltévednek a csomagok, vagy ez valami belső kernel móka miatt van? Vagy mi egyéb lehet? Ha minden olyan szabályt/policy-t kiveszek, ami eldob csomagot, az sem segít. Ezért állok értetlenül a probléma előtt...

Előre is köszi,
fincsi