Sziasztok!
Adott három XEn virtuális gép, amelyek NAT-olva mennek a netre.
Egymást tudják pingelni, de egymás szolgáltatásait nem tudják használni.
Például a 10.0.0.1 ről telnettel próbálom a 10.0.0.2 80-as portját, de nem megy.
Ha pingelem (ICMP), az működik.
Van valami egyéb tennivaló, hogy a VM-ek lássák egymást?
Köszi!
Helló MindekiNet.
Egy proxy-t szeretnék beállítani, futna rajta Squid, ntop + egyéb nyalánkság, és egy pár(~5db) gépet natolna a külvilág felé, mindenki másnak ott a Squid.
Csak éppen nem t'om eldönteni, hogy Debian vs. FreeBSD legyen az alap. Iptables vagy IPFilter + IPNat a nyerő. Szerintem egyik sem jobb a másiknál :-)
Viszont Debiant és Iptablest biztosan többen használnak az országban, mint FreeBSD-t. Munkahelyen is az Iptables kimagasló ismeretét várják el.
Esetleg ha van valakinek valamilyen értelmes gondolata, ami új megvilágításba helyezi a dolgokat. kérem osza meg velem.
Sziasztok!
A következő helyzet adott:
Régi szerver:
Debian Etch (x86), Xen 3.0.3-1, LVM, rajta DRBD8, ezen domU-k.
Új szerver:
Debian Lenny (x64), Xen 3.2-1, LVM, Rajta DRBD8, ide migrálnék.
A DRBD tükör működik, szinkronizálás megtörtént, mindkét szerver primary szerepkörben dolgozik. Elvileg minden adott egy kiadós live migration végrehajtására. Azonban...
A migrálás nem indul el. A logban ez szerepel:
Saving memory pages: iter1 0%Error when writing to state file (2): 32
Nem tudom, mi lehet a baja: eltérő Xen verziók, vagy kihagytam valami alapvetően fontos dolgot.
Több órás keresgélés (google) után sem találok megoldást.
Van valakinek ötlete?
Köszönettel:
Attila
Sziasztok!
Szeretnék Linuxot bootolni NFS megosztás használatával.
Eddig Slax és Mandrivát (most épp' ez utóbbit) próbáltam, de sikertelenül.
Tehát hálózatról bootolom be a rendszert, de az NFS megosztást valamiért nem használja (illetve utalást sem fedeztem fel a feliratok között rá), holott néhány oldalon láttam leírást, elvileg Mandrivának is mennie kellene. Konkrétan 2009.1 RC2 KDE-s live lemezével próbálkoztam, a vmlinuz és initrd.gz is erről való (ez lenne a baj?).
Az NFS megosztást másik gépen próbálva rendesen becsatolható és használható.
Az egyes fileok ezzel összefüggő sorai így néznek ki:
/etc/exports:
/nfs/Mandriva 192.168.0.0/255.255.0.0(rw,no_root_squash)
pxelinux.cfg
Label Mandriva_NFS
MENU LABEL Mandriva NFS
kernel /boot/Mandriva/vmlinuz
append initrd=/boot/Mandriva/initrd.gz splash=silent vga=788 netboot=nfs nfsroot=192.168.10.1:/nfs/Mandriva/
Szerintetek mi nincs rendben?
Hello!
Szeretnek osszerakni wifi auth-hoz radius-t eap-ttls/eap-peap, ldap, kodolt jelszavakkal es hasonlokkal.
Elakadtam az eap resznel (sima radtest-el okes a dolog), ha radeapclient-el tesztelni akarnam akkor az tortenik, h szerver megtalalja a usert, visszakuld egy access-challange uzenetet es befejezi, mikozben a kliens meg uzenne neki:
...
rad_recv: Access-Request packet from host 127.0.0.1 port 52650, id=76, length=69
User-Name = "steve"
NAS-IP-Address = 127.0.0.1
Message-Authenticator = 0xafa8ae1b1aaa6fb0a6cbd0719b507e94
NAS-Port = 0
EAP-Message = 0x02d2000a017374657665
+- entering group authorize {...}
++[preprocess] returns ok
[suffix] No '@' in User-Name = "steve", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 210 length 10
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry steve at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Found existing Auth-Type, not changing it.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type md5
rlm_eap_md5: Issuing Challenge
++[eap] returns handled
Sending Access-Challenge of id 76 to 127.0.0.1 port 52650
Service-Type = Framed-User
Framed-Protocol = SLIP
Framed-IP-Address = 192.20.126.200
Framed-IP-Netmask = 255.255.255.0
Framed-Routing = Broadcast-Listen
Framed-Filter-Id = "std.ppp"
Framed-MTU = 1500
Framed-Compression = Van-Jacobson-TCP-IP
EAP-Message = 0x01d300160410b7703d97cfb88bff2835ec9a9aedde83
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xae48086bae9b0cd33d7dacc7cd15f18d
Finished request 2.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 2 ID 76 with timestamp +94
Ready to process requests.
localhost-rol kliens:
# radeapclient -s -X localhost auth testing123
+++> About to send encoded packet:
User-Name = "steve"
Cleartext-Password = "testing"
NAS-IP-Address = 127.0.0.1
EAP-Code = Response
EAP-Id = 210
EAP-Type-Identity = "steve"
Message-Authenticator = 0x30
NAS-Port = 0
Received response ID 76, code 11, length = 131
Service-Type = Framed-User
Framed-Protocol = SLIP
Framed-IP-Address = 192.20.126.200
Framed-IP-Netmask = 255.255.255.0
Framed-Routing = Broadcast-Listen
Filter-Id = "std.ppp"
Framed-MTU = 1500
Framed-Compression = Van-Jacobson-TCP-IP
EAP-Message = 0x01d300160410b7703d97cfb88bff2835ec9a9aedde83
Message-Authenticator = 0xe65c832fea00201e76a340cc0e38cf37
State = 0xae48086bae9b0cd33d7dacc7cd15f18d
<+++ EAP decoded packet:
Service-Type = Framed-User
Framed-Protocol = SLIP
Framed-IP-Address = 192.20.126.200
Framed-IP-Netmask = 255.255.255.0
Framed-Routing = Broadcast-Listen
Filter-Id = "std.ppp"
Framed-MTU = 1500
Framed-Compression = Van-Jacobson-TCP-IP
EAP-Message = 0x01d300160410b7703d97cfb88bff2835ec9a9aedde83
Message-Authenticator = 0xe65c832fea00201e76a340cc0e38cf37
State = 0xae48086bae9b0cd33d7dacc7cd15f18d
EAP-Id = 211
EAP-Code = Request
EAP-Type-MD5 = 0x10b7703d97cfb88bff2835ec9a9aedde83
+++> About to send encoded packet:
User-Name = "steve"
Cleartext-Password = "testing"
NAS-IP-Address = 127.0.0.1
EAP-Code = Response
EAP-Id = 211
Message-Authenticator = 0x00000000000000000000000000000000
NAS-Port = 0
EAP-Type-MD5 = 0x106e2008d8fc099a16335131c045fc6df6
State = 0xae48086bae9b0cd33d7dacc7cd15f18d
^C
# cat re.txt
User-Name = "steve"
Cleartext-Password = "testing"
NAS-IP-Address = 127.0.0.1
EAP-Code = Response
EAP-Id = 210
EAP-Type-Identity = "steve"
Message-Authenticator = 0
NAS-Port = 0
A freeradius szerver 2.1.4-es forrasbol sima dpkg-buildpackage-el keszitett debian csomag (nem modositgattam a konfigokon, amennyire neztem benne volt ami kellett alapbol, pl tls).
Mit ronthattam el vagy mi hianyzik?
Sziasztok!
A minap találtam ezt az oldalt http://lwn.net/Articles/143397/ ami felkeltette az érdeklődésemet. Tartok otthon 0/24-ben működő NSLU2-t, amire csatlkakozik egy notbHDD, amin a rendszer van, valamint kb hetente egyszer egy külső hagyományos HDD, amit csak úgy szeretnék csatlakoztatni, hogy áramot adok a tápjára, de az usb-t nem húzom ki majd dugom vissza a küttybe.. Magyarul mindig csatlakoztatva van az USB, csak a táp van lekapcsolva. Viszont, tapasztalatom szerint a mount csak akkor működik, ha ki-be dugom az USB csatlakozót.
Megpróbáltam a fenti link szerinti eljárást, de sajnos no such device üzenetet dobál vissza..
Esetleg vki járt már hasonló cipőben? Szívesen venném, ha valaki tudna segíteni ebben.
Köszönöm!
Sziasztok!
Egy ideje hiába próbálkozom újabb kernelt fordítani, nem sikerül feltenni.
A jelenlegi kernelem 2.6.27.18, a 27-es sorozatig minden működött.
2.6.28-tól kezdve a következő hibaüzenetet kapom, mkinitrd-től:
Creating initramfs
Found root device /sys/block/hda//hda7 for /dev/hda7
Looking for driver for device /sys/block/hda//hda7
Looking for deps of module ide:m-disk
No module ide_disk found for kernel 2.6.29.1, aborting.
Nézegettem a configot ill. config file-t, de seholsem találok ide_disk modult.
A rendszer egy x64-es Mandriva 2008.1
Mit tegyek vele, hogy végre felkerüljön a gépre?
Nem tudom, van-e azzal összefüggés, hogy újabban IDE meghatókat is "SCSI-ként" kezelnek.
Egy Ubuntu 8.04 -es gépen szeretnék mappákat felcsatolni a szerver-ről. A szerveren fedora van samba kiszolgálóval telepítve.
Az fstab -ba beírtam az alábbi sort:
//10.0.0.251/server /home/user/server smbfs auto,user,exec,ro,username=felhasználónév,password=jelszó 0 0
A probléma, hogy fel is csatolja a könyvtárat és tökéletesen működik újraindításig, de újraindítás után a /home/user/server könytár tulajdonosát (ismeretlenre) teszi és a jogosultságot is átállítja 777 -ről. Így nem tudom autómatikusan felcsatolni, csak root jogokkal. Nem értem miért változtat jogokat és felhasználót az újraindítás után az adott könyvtárra ahova mountolni szeretném. Win esetén tökéletesen múködnek a felcsatolások, de most szeretnék az új gépekre ubuntu-t telepíteni, de ha nem tudom ezt megoldani, akkor a kollegáknak nem lesz hálózati meghajtójuk.
Mellesleg ha a csatolást a /mnt/server könytárba csinálnám, ott is ugyan ez történik. Tehát ennek nincs jelentősége.
Valakinek valami ötlet, mert én kifogytam belőle? Légyszi segítsetek!
Sziasztok!
Összeraktam a fentebb említett kombót squid-el kiegészítve..
Működik, viszont a letöltendő nagyobb fájlok nagy részét nem ellenőrzi le, be sem ugrik a dansguardian download manager-e hanem egyből adja a letöltőablakot..
A logban nem látok semmit..
Viszont van ahol jó, ezért nem is értem mi lehet vele.. Esetleg találkozott valamelyikőtök hasonló problémával?
Apropó még egy kérdés, ha szabad.
Azt mivel tudom beállítani, hogy a download man. hamarabb jöjjön be? Most jelenleg kb 10mp-et vár mire beugrik.. ennyi idő alatt az átlag juser, legalább 3szor kattint újból a letöltésre.
Sziasztok!
Egy (beismerem kissé kusza) DHCP/DHCP-RELAY egyveleg szivat, ebben kéne egy kis segítség vagy infó.
Ez egy főiskola hálózata, ahol van két Windows AP fa, és egy jópár vlan. A Windows domain-ben lévő gépek DHCP szervere a megfelelő Windows szerver. Ahol nem kapcsolódnak közvetlenül a kliensek, ott (általában) egy ProCurve 5406zl switch továbbítja a DHCP kéréseket, és a switch a router is.
Néhány VLAN-ban ahol a gépek nincsennek a domain-ben, ott a DHCP szerver (és a defaulr router/tőzfal-is) egy ubuntu szerver (8.04). Van egy VLAN (ez keverte meg a dolgokat), ahol a gépek Windows kliensek, beléptetve a domain-ba, de ezek egyébb okok miatt az Ubuntu tűzfal mögött vannak. Ennek néhány következméne:
Mivel ebben a VLAN-ban az 5406zl-nek nincs IP címe (nem ő rout-ol) nem lehet ő a DHCP-RELAY sem.
Egyébb okokból a tűzfal nem kapcsolódik ahhoz a VLAN-hoz amiben a DHCP SZERVER van:
(kliens gépek, VLAN3038)---[tűzfal ubuntu]---(VLAN3001)---[router 5406zl]---( DHCP szerver, VLAN3016 ).
A VLAN3001-ben is van ugye egy DHCP szerver, de az egy másik domain.
A felállás tulajdonképpen működik, csak van egy szépséghibája. A tűzfalon futó dhcp-relay szerver hallgatózik a vlan3038, és vlan3001-es interfészen is, ezért ha a vlan3001-ből jön egy DHCP kérés, akkor azt is továbbítja a vlan3016-ban lévő DHCP szerver felé, amit a DHCP szerver eldobb, mert a 3001-es vlan nem rá tartozik.
Úgy gondoltam, hogy ezt a kis szépséghibát tűzfal szabályokkal megszüntetem. Megírtam a tűzfalszabályokat, és nem működnek, csak annyi derült ki számomra, hogy valamit NAGYON NEM ÉRTEK.
A jelenség:
A tűzfal szabályok (input oldal, számlálókat töröltem, hogy ne legyenek tú hosszú sorok):
Chain INPUT (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all -- lo any anywhere anywhere
internetioi all -- eth1 any anywhere anywhere
ACCEPT icmp -- any any anywhere anywhere
tunioi all -- tun+ any anywhere anywhere
dhcpdioi udp -- any any anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
...
Az INPUT láncban (az eth1-az internet felé néz) a DHCP-vel kapcsolatba hozható csomagok mennek a dhcpdioi láncra:
Chain dhcpdioi (1 references)
target prot opt in out source destination
ACCEPT udp -- eth0 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3059 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3060 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3038 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3001 any anywhere anywhere udp spt:bootps dpt:bootps
LOG all -- any any anywhere anywhere LOG level warning prefix `DROP_DHCPi'
DROP all -- any any anywhere anywhere
Az eth0, vlan3059, vlan3060, vlan3038 -on fogadom a DHCP kéréseket a kliens felöl, a vlan3001-en fogadom a választ a DHCP szerver felől, minden mást loggolok, és eldobok. Ez alapján eldobom (el kellene dobni) a vlan3001-ből jövö DHCP kéréseket is.
Ehez képest a tcpdump eredménye, ha egy DHCP kérés érkezik a vlan3001-ből:
08:29:27.015699 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:f1:e4:c9:70, length 300
08:29:27.016106 IP 172.20.1.253.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
08:29:27.018611 IP 172.20.1.3.67 > 172.20.16.254.67: BOOTP/DHCP, Request from 00:0c:f1:e4:c9:70, length 300
A kliens kérésére (1.blokk) megjön a válasz az ottani dhcp szervertől (172.20.1.253), majd a harmadik blokkban látszik, hogy a dhcp-relay is továbbítja a kérést az általa ismert DHCP szervernek. Ha az első blokk el vagyon dobva, akkor mit keres a dump-ban, és miért válaszol rá bárki. A dhcpdioi láncban látszik is a találat az utolsó két szabályra, és ez a kernel log-ban is látszik:
Mar 20 08:51:33 mano kernel: [169919.075936] DROP_DHCPiIN=vlan3001 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:f1:e4:c9:70:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Bár ez a kis anomália nem okoz a kliensek szempontjából problémát, de engem nagyon elbizonytalanított.
Valaki homályosítson fel, mi a fene történik itt.