Re: [lmn] OT: Monitor für Aula
Hallo Frerk, > Den tabula-Service haben wir auf einem virtualisierten Ubuntu auf > unserem zentralen Server laufen. Ist allerdings noch nicht im regulären > Betrieb, wir machen erst weiter wenn die neuen Monitore eintreffen. sind die Monitore eingetroffen? Welche hast du den nun? Und welche Gehäuse? Raspi im Gehäuse oder Rechner im Nebenraum? Ich muss auch auf einen Brandgeschützten Monitor umsteigen .. Viele Grüße Holger -- Mein öffentlicher PGP-key ist hier hinterlegt: pool.sks-keyservers.net ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Coovachilli und DHCP-Adressen --- gelöst??!??
Am Sonntag, 31. Mai 2015, 21:29:24 schrieb Michael Hagedorn: > > Da sollte eigentlich jetzt 172.20.8.1 stehen ... > > *JUBEL* > > Manchmal muss man einfach nur einen halben Tag lang **nichts** machen -- > und dann läuft es! > > Ich habe mich vorhin (eigentlich nur um zu schauen, ob es noch > funktioniert) mit einem Usernamen/Passwort anstelle per MAC über den > Controller, der die **feste** IP bekommen soll, am coova angemeldet -- > und siehe da: > > 94-D7-6C-4D-FD-B3 172.20.8.1 pass 0/2700 -- so wie es sein soll! > > Er hat's also endlich umgesetzt -- weiß der Geier, warum das nicht > sofort lief?!? Es bleibt aber noch zu prüfen, ob das nun zuverlässig > klappt und auch so bleibt... > > Falls nun größeres Interesse an der Vorgehensweise für statische IPs im > WLAN besteht, kann ich's demnächst mal ins Wiki setzen > ... falls nicht: Auch ok :) > Hallo Michael, zunächst einmal Glückwunsch. Ich habe mit Interesse mitgelesen und würde mich freuen, das im Wiki zu finden. Gruß, Frank Schütte ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Coovachilli und DHCP-Adressen --- gelöst??!??
> Da sollte eigentlich jetzt 172.20.8.1 stehen ... *JUBEL* Manchmal muss man einfach nur einen halben Tag lang **nichts** machen -- und dann läuft es! Ich habe mich vorhin (eigentlich nur um zu schauen, ob es noch funktioniert) mit einem Usernamen/Passwort anstelle per MAC über den Controller, der die **feste** IP bekommen soll, am coova angemeldet -- und siehe da: 94-D7-6C-4D-FD-B3 172.20.8.1 pass 0/2700 -- so wie es sein soll! Er hat's also endlich umgesetzt -- weiß der Geier, warum das nicht sofort lief?!? Es bleibt aber noch zu prüfen, ob das nun zuverlässig klappt und auch so bleibt... Falls nun größeres Interesse an der Vorgehensweise für statische IPs im WLAN besteht, kann ich's demnächst mal ins Wiki setzen ... falls nicht: Auch ok :) Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Coovachilli und DHCP-Adressen: Einige Clients fest eintragen???
> radtest -x 94-D7-6C-4D-FD-B3 94-D7-6C-4D-FD-B3 127.0.0.1 0 Klappt > So falsch ist das alles also nicht ... übernommen wurde die > Einstellung allerdings noch nicht ... und noch ein Puzzlestückchen mehr: tail /var/log/linuxmuster-chilli/coova-chilli.log chilli.c: 5117: New DHCP request from MAC=94-D7-6C-4D-FD-B3 ippool.c: 486: Static out of range <<< !!! aha!? <<< chilli.c: 4950: Granted MAC=94-D7-6C-4D-FD-B3 with IP=172.20.0.101 access without radius auth Da sollte eigentlich jetzt 172.20.8.1 stehen ... Die Fehlermeldung habe ich schon erfloglos "er-$suchmaschint" -- Systemdaten: - virtualisiert mit Proxmox 2.3 - linuxmuster.net 6.0.46 - IPFire 2.15 - Linbo 2.1.10-0 - Ubuntu 14.04 Clients (trusty714-Vorlage) - leoclient1 mit WinXP im offline-Modus - Moodle 2.7.8 (extern mit LDAPS und openLML-Modul) - WLAN: Unifi-APs (UAP-AC) am CoovaChilli - Info-Boards: tabula.info Server + RasPi-Clients ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Coovachilli und DHCP-Adressen: Einige Clients fest eintragen???
Moin jonny! >>> was dir vielleicht nicht klar ist: in der vm sind eigentlich 2 getrennte >> Danke für die Mini-Fortbildung. War mir in der Tat *so* nicht klar! >> Aber wieder gilt: Da der linuxmuster-chilli alles bereits unter einem >> Dach vereint, würde ich den auch am liebsten so benutzen, wie es ist. > ich denke eben, daß du dein system dadurch unnötig unsicherer machst. Wodurch genau meinst du jetzt? Nur deshalb, weil da ein zusätzliches Gerät mit im Netz hängt -- oder meinst du jetzt die Sache mit der MAC-Auth? Die ist hier ja sowieso aktiviert, damit gewissen Stationen sich nicht anmelden müssen bzw beim "disconnect" angemeldet bleiben. Von daher "muss" ich diesen Schwachpunkt in Kauf nehmen... > deine mac notation ist korrekt. > ich sehe dein problem eher bei den operatoren. ein einfaches = ist hier > sogut wie immer falsch. Ich habe die Manpage (man 5 users) bereits gelesen ... allerdings wurde die gleiche Syntax mit den gleichen Operatoren wie bei mir auch in den mitgelieferten Beispielen benutzt. Soo falsch kann sie dann ja nicht sein?? Ich bin auch schon über diesen Eintrag gestolpert: Auth-Type := Accept (der allerdings als "schlechte Idee" gekennzeichnet wurde http://wiki.freeradius.org/config/Auth-Type ) > vielleicht führt dich dein fund des mac2ip moduls da schneller weiter. Das war die Hoffnung ... aber die hast du > aber bedenke, daß dies dann auch nur die radiusseite ist und du evtl > noch den anyip patch im chilli brauchst ... gerade wieder zerstreut :) Es ist leider nach wie vor irrtierend, dass in fast allen Anleitungen, die man so findet, von SQL sowie Konfigurationen unter raddb gesprochen wird --- diese Dateien aber auf dem linuxmuster-chilli z.T. gar nicht existieren; vgl. z.B.: http://wiki.freeradius.org/guide/Mac-Auth Da hilft mir das schönste Manual dann nur bedingt weiter :( So z.B. das Stichwort "FreeRADIUS > Settings, Enable Plain MAC Auth to enable plain MAC auth" wenn ich's richtig überblicke, muss diese Einstellung ggf. noch überprüft/aktiviert werden... nur wo? Eine Sache hat dann aber gerade *doch* geklappt: radtest -x 94-D7-6C-4D-FD-B3 94-D7-6C-4D-FD-B3 127.0.0.1 0 liefert erfreulicherweise dies: Sending Access-Request of id 81 to 127.0.0.1 port 1812 User-Name = "94-D7-6C-4D-FD-B3" User-Password = "94-D7-6C-4D-FD-B3" NAS-IP-Address = 172.16.16.10 NAS-Port = 0 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=81, length=32 Framed-Protocol = PPP Framed-IP-Address = 172.20.8.1 (Anm. der Red.: "Liebe Schüler: die Mac-Adresse ist natürlich ausgedacht!") So falsch ist das alles also nicht ... übernommen wurde die Einstellung allerdings noch nicht Michael Systemdaten: - virtualisiert mit Proxmox 2.3 - linuxmuster.net 6.0.46 - IPFire 2.15 - Linbo 2.1.10-0 - Ubuntu 14.04 Clients (trusty714-Vorlage) - leoclient1 mit WinXP im offline-Modus - Moodle 2.7.8 (extern mit LDAPS und openLML-Modul) - WLAN: Unifi-APs (UAP-AC) am CoovaChilli - Info-Boards: tabula.info Server + RasPi-Clients ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einrichtung Subnets - kein DHCP auf Clients
Hallo zusammen, also zunächst mal: der Computer-Raum, in dem ich sitze, tut wieder, die Clients starten und bekommen DHCP, und man kann sich normal anmelden. D.h. dass wieder alles soweit funktioniert :) Allerdings habe ich nicht den Eindruck, dass die subnets richtig eingerichtet sind. Ich stell mal ein paar Verständnisfragen: 1.) Ich habe nun also den virtuellen switch der ESXi-Maschine (an dem Server und IPFire hängen) an den Port des Cisco gehängt, der VLAN 11 ungetagged hat. Wie kommen denn nun die anderen VLANS in das Netz? Ich dachte, ein ungetaggter Port (VLAN11) würde alles außer dem Servernetz rausfiltern? 2.) Um das nochmal ganz klar zu machen: in der /etc/linuxmuster/workstations muss die Netzwerkmaske der einzelnen Geräte 255.255.255.0 sein, und nicht mehr 255.240.0.0? Im Augenblick habe ich einige Clients dort immer noch mit Netzwerkmaske 255.240.0.0 eingetragen und die funktionieren trotzdem. Der mit 255.255.255.0 allerdings auch :P 3.) Andererseits habe ich gerade ein Notebook mit einer IP aus einem bestimmten Raum (= VLAN 102) in die Workstations eingetragen - wenn ich das an den dicken Switch an einen Port hänge, der diesem VLAN zugeordnet ist, dann bekommt es eine IP. An einem anderen Port bekommt es keine. Das heißt doch, dass dieses subnet wie gewünscht funktioniert? Dieses Notebook funktioniert übrigens auch an einem (weiteren) untagged VLAN11-Port des Cisco, es bekommt die richtige IP - 10.16.1.50 mit subnet-mask 255.255.255.0 und Vorgaberoute 10.16.1.253. 4.) Ich habe die VMWare-Doku mal nach VLAN-Tagging durchforstet, da gibt es eine Menge Anleitungen. Wenn ich es richtig sehe, dann muss ich die Variante VGT (Virtual Guest Tagging) verwenden: http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.networking.doc%2FGUID-7225A28C-DAAB-4E90-AE8C-795A755FBE27.html Zitat: "Beim VGT wird das gesamte VLAN-Tagging von der virtuellen Maschine durchgeführt. VLAN-Tags werden zwischen dem VM-Netzwerkstapel und dem externen Switch beibehalten, wenn Frames an und von virtuellen Switches übergeben werden. Ports des physischen Switches sind auf Trunk-Port eingestellt." Eine Anleitung dazu findet sich z.B. hier: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1004252 Zitat: Configuration of VirtualSwitch (vSwitch) To set a standard vSwitch portgroup to trunk mode: Edit host networking via the Virtual infrastructure Client. Navigate to Host > Configuration > Networking > vSwitch > Properties. Click Ports > Portgroup > Edit. Click the General tab. Set the VLAN ID to 4095.A VLAN ID of 4095 represents all trunked VLANs. Click OK. Ich habe aber eben testweise die VLAN ID von 4095 wieder auf 0 (kein VLAN) zurückgestellt - keine Veränderung, es geht immer noch alles :P Sorry, ich bin zwar froh, dass das ganze irgendwie tut, aber ich bin grad ziemlich überfordert. Wie kann ich denn (noch) testen, ob die subnets richtig funktionieren? Vielen Dank und viele Grüße, Marcus Am 31.05.2015 um 00:20 schrieb Holger Baumhof: Hallo marcus, Nach meinem Verständis der Anleitung müsstest du die "grüne" Netzwerkkarte des VM-Hosts an den Switch-Port fürs VLAN Server hängen und nicht an den Port VM-Host. .. das sehe ichauch so, wenn ich den Begriff "VM HOst" richtig deute. Welche virtualisierung verwendest du den? Das ganze ist nicht so einfach, da der Server die Pakete an die Räume schon getagged aus dem Server rausschickt: wenn du dazwischen einen virtuellen switch hast, dann muss er VLANs können, sonst nimmt er unter Umständen einfach den Tag weg und dann war es das mit den VLANs. Lass dich auch nicht davon ablenken, dass auf dem VM Host (wie in der Anleitung beschrieben: bei KVM) nur die VLANs 10 11 12 und 13 als VLANs auftauchen ( /etc/network/interfaces auf dem Host): das macht nichts, die Pakete kommen schon getagged. Das ist das eine Ende. Das andere Ende ist, dass auf dem Cisco für den DHCP sogenannte IP Helper (oder heißt das bei cisco DHCP Helper?) aktiv sein müssen. Desweiteren muß die Netzwerkmaske stimmen: 255.255.255.0, nicht mehr 255.240.0.0 Wenn du meinst, dass der Fehler nicht am VM Host liegt, dann empfehle ich dir, den cisco zu resetten auf Werkseinstellungen und ihn nochmal Schritt für Schritt nach der Anleitung von Thomas zu konfigurieren. Ist die neuste Firmware auf dem cisco? Das würde ich auf jeden Fall vorher machen. VIele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
