Re: [lmn] Coova-Problem - falsche IP?
Hallo zusammen, das Problem war ein falsch konfigurierter und falsch verkabelter AccessPoint. Danke für' Mitdenken. Ein schönes Wochenende Gruß christian Am 10.11.2016 um 23:35 schrieb Holger Baumhof: > Hallo Christian, > >>> Also: nochmal genau hinschauen. >> Keine Ahnung, keiner von meinen Servern jedenfalls. >> Das Seltsame ist, dass ich eben den coova wieder mit dem Switch >> verbunden habe >> und nun vom Coova per (wlan) noch immer die falsche Ip bekomme, es aber >> jetzt wieder so >> schnell ist wie vorher. > .. *verwirrt* .. du bekommst jetzt über WLAN wieder eine falsch IP? > Steck mal den Coova nochmal ab und versuch es dann nochmal per WLAN und > nicht per Kabel. > Hat dir jemand einen Honeypot in die Schule gestellt? > Ein Accesspoint, der so heißt wie deine, dich aber in ein anderes Netz holt? > > Und für einen Crosscheck: > mach einen anderen (kleinen) switch an den coova und häng da auch mal > das Notebook dran. > Gibt es da eine IP? > Welche? > > und zu guter Letzt: wie hast du virtualisiert? > KVM? > Schau mal nach, ob der DHCP auf dem virtuellen Switch eingeschaltet ist. > > VIele Grüße > > Holger > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Coova-Problem - falsche IP?
Hallo Holger, für die schnelle Antwort. Am 10.11.2016 um 17:56 schrieb Holger Baumhof: > Hallo Christian, > > ein tausch der Switches verwirrt den Coova nicht: du hast einen weiteren > DHCP im Netz: irgendjemand hat da was falsch gesteckt. das ist gut zu wissen :-) > > Also: steck mal den Coova aus und häng dann dein Laptop (z.B. an genau > dieser Stelle) ins Netz und frag mal nach, ob es da einen DHCP gibt ... > > Wenn ja: fang an an diesem Switch andere Kabel ab zu ziehen, bis der > DHCP nicht mehr antwortet :-) der Laptop bekommt keine IP zugewiesen. > > Wer gibt den 192.168.169.x Adressen raus? > Hast du da mit Windows getestet? > Weil da gibt es 169.x.y.z Adressen, die sich WIndows selber gibt, wenn > er garkeinen DHCP findet.. > Also: nochmal genau hinschauen. Keine Ahnung, keiner von meinen Servern jedenfalls. Das Seltsame ist, dass ich eben den coova wieder mit dem Switch verbunden habe und nun vom Coova per (wlan) noch immer die falsche Ip bekomme, es aber jetzt wieder so schnell ist wie vorher. > > Viele Grüße > > Holger > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user Gruß ch ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] owncloud ein Erfahrungsbericht
Hallo Holger, ich habe den Hinweis hier gefunden: https://github.com/owncloud/core/issues/25557 : Einer der an der Diskussion beteiligten Personen (gongyllun am 24.7.2016) hat die oc_shares gelöscht, danach ging es wieder Also habe ich, als alles anderen nicht gefunzt hat, die oc_shares mittels phpmyadmin gelöscht. Das war auch schon. Das ist mit Sicherheit keine elegante Lösung, aber bei mir am Ende die einzige, die funktioniert hat. Die Patches, die empfohlen wurden, haben allesamt keinerlei Wirkung gezeitigt. Viele Grüße Christian Am 06.10.2016 um 20:46 schrieb Holger Baumhof: > Hallo oChristian, > >> ich hatte auch ziemliche Probleme bei den letzten Updates von Owncloud >> vor allem von 9 auf 9.1. Da auch nach langem Suchen keine Lösung in >> Sichtweite war, blieb mit nur übrig, die oc_shares zu löschen. Damit >> waren alle geteilten Dateien weiterhin vorhanden, aber eben nicht mehr >> geteilt. > > nach sowas hatte ich gesucht: aber nicht gefunden. > Wie kann man den die shares alle enternen? > > Vielelicht hilft das ja bei meiner oc, jetzt nc10.. > Arg viel Hoffnung hab ich nicht, da ich schon versucht hatte shares zu > entfernen und dann wieder an zu legen: das Problem blieb. > > LG > > Holger > 0x8BBF611B.asc Description: application/pgp-keys ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] owncloud ein Erfahrungsbericht
Nabend zusammen, ich hatte auch ziemliche Probleme bei den letzten Updates von Owncloud vor allem von 9 auf 9.1. Da auch nach langem Suchen keine Lösung in Sichtweite war, blieb mit nur übrig, die oc_shares zu löschen. Damit waren alle geteilten Dateien weiterhin vorhanden, aber eben nicht mehr geteilt. Das hat einige Kollegen genervt, aber immerhin läuft OC 9.1 jetzt wieder, ohne dass ich von nennenswerten Problemen wüsste. Klar ist aber, dass ich keine Updates mehr machen werden. Werde die Sache jetzt mal beobachten und schauen, wie sich Nextcloud und Owncloud weiter entwickeln. Viele Grüße Christian Huber Am 06.10.2016 um 19:01 schrieb Jesko Anschütz: > Hi zusammen, > > Ich hab mir am Dienstag auch meine Owncloud gesprengt. > Weil mich schon in der Vergangenheit meine „mach mal schnell ’n > Update…“-Strategie einige Haare gekostet hat, habe ich mit mysqldump die > Datenbank und mit rsync das Verzeichnis gebackupt, ohne allerdings zu > verifizieren, ob das auch korrekt verlaufen ist (ich ging davon aus). > > Langer Schwede kurzer Finn: > Das Update von 8.1 auf 8.2 lief sauber durch, aber nach 9 gab es einen > Fehler, der nicht näher spezifiziert wurde und meine Owncloud kaputtgemacht > hat. > das rückspielen der Datenbank und zurückkopieren der Dateien hat leider keine > funktionierende Owncloud produziert. > > Ich hatte die Faxen dicke und hab jetzt nextcloud 10 installiert…. > hoffen wir das Beste… > > LG, Jesko > > > >> Am 06.10.2016 um 10:38 schrieb Holger Baumhof : >> >> Hallo zusammen, >> >> ich wollte mal berichten, wie es mir in den letzten zwei Wochen mit der >> owncloud ergangen ist. >> >> Vorneweg möchte ich sagen: die owncloud, von Nutzerseite aus, ist super: >> die funktionen sind sehr vielfältig und selbst von "unerfahrenen" >> Nutzern bedienbar. >> Weder das Semianr och die Schule könnten sich vorstellen, wieder ohne >> owncloud aus zu kommen. >> >> Von der admin Sicht her allerdings ... >> >> Aber von Anfang an: ich hab vor ein paar Jahren die owncloud im Seminar >> und in der Schule installiert: das dürfte owncloud 7 damals gewesen sein. >> Seit dem gab es kein Update, das einfach funktioniert hätte. >> Vor allem das updaten über die Paketverwaltung hat kein einziges mal >> funktioniert. >> Und wir reden von etlichen updates: alleine von 8.0 auf 8.1 auf 8.2 auf 9.0 >> >> Also: jedes mal das tar.gz runtergelden, entpackt, kopiert und dann occ >> upgrade ausgeführt. >> Das funktionierte .. bis das update von 9.0 auf 9.1 kam: letzte WOche. >> Auch das upgrade funktionierte, allerdings war die owncloud danach >> nurnoch halb so schnell, NUtzer berichteten von trägen syncs und >> seltsamen Verhalten der syncclients. >> Und am schlimmsten: geshrten Dateien wurden immer kolonnen von (2)ern >> angehängt. >> Das sah dann so aus: >> dokument.odt(2)(2)(2)(2)(2)(2)(2)(2)(2)(2)(2)(2)(2)(2)(2) >> .. nur viele mehr .. >> sharen ging also nicht mehr: man konnte die Dateien/Ordner nicht mehr >> öffnen. >> >> Ich hab 2 Tage lang gesucht: aber keine Lösung gefunden. >> Also hab ich mir selber Lösungen ausgedacht. >> Zuerst hab ich mal die mysql durch eine mariadb ersetzt: soll viel >> performanter sein dun einige seltsamkeiten mit der owncloud beheben: das >> Ersetzen war unglaublich einfach >> apt install mariadb >> Dabei wird mysql entfernt und vollständig und transparent durch mariadb >> ersetzt. Hat nix gebracht. >> Dann dachte ich: Flucht nach vorne: und hab auf nextcloud 10 upgedatet: >> ging ohne Probleme: aber die performance und shareproblem blieben: >> scheint wohl ein Fehler in der DB zu sein, den mir das update auf 9.1 >> beschert hat. >> Nach 10 Tagen rumprobieren strich ich die Segel und hab am Montag das >> Backup an die Stelle der owncloud gesetzt: jetzt läuft wieder die 9.0 >> >> Doch dann geschah das ganz Schlimme: die syncclients löschten lokal die >> Dateien, die die owncloud 9.0 nicht kannte: also alle, die seit dem >> update auf 9.1 hinzugekommen waren.. >> >> Ich hatte Glück: ich habe die nextcloud 10 noch: also hab ich die unter >> einer anderen IP laufen und hab den Usern geschrieben, wo sie ihre >> Dateien finden.. >> >> Alles in allem möchte ich sagen: macht kein update der owncloud ohne >> funktionierndes Backup. >> >> Ich werde in ein paar Wochen die owncloud zu einer nextcloud 10 >> migrieren in der Hoffnung, dass ich so in ruhigere Fahrwasser komme. >> >> Viele Grüße >> >> Holger >> >> >> >> -- >> Mein öffentlicher PGP-key ist hier hinterlegt: pool.sks-
Re: [lmn] owncloud update
Hallo zusammen, das LDAP-Problem beim Update auf OC9.1 lässt sich zumindest umgehen, indem man die File-Sharing-App deaktiviert: https://central.owncloud.org/t/csrf-check-failed-after-upgrade-to-9-1/922/8 Somit können sich die Nutzer immerhin wieder anmelden. Allerdings ist das natürlich keine dauerhafte Lösung, da das Teilen von Dateien ja der Grund ist, warum wir Owncloud überhaupt einsetzen. Man hat im Moment scheinbar nur die Wahl zwischen Pest und Cholera. Gruß christian huber Am 28.07.2016 um 10:02 schrieb Wilfried Larisch: Hallo Holger, Am 28.07.2016, 01:31 Uhr, schrieb Holger Baumhof : Hallo Wilfried, nachdem im Administrationsbereich als stable die Version 9.0.4 erschienen ist, habe ich dort das update von 9.0.2 aus angestoßen. Es lief zwar fix und laut Meldungen fehlerlos durch, allerdings konnte ich mich danach zwar noch anmelden, aber dann kam eine apache-Fehlermeldung den Port 443 betreffend und sonst nix mehr. Da ich nicht lange suchen wollte, habe ich ein Backup des Owncloudservers zurückgespielt. Im Owncloudforum habe ich dazu nichts gefunden. Sobald ich Zeit (und Lust) habe, werde ich das 'Manually upgrading" mit dem tar-Archiv probieren. ich habe meine owncloud von 8.2.2 auf 8.2.7 und dann auf 9.04 upgedatet, indem ich dieser Anleitung gefolgt bin: https://doc.owncloud.org/server/9.0/admin_manual/maintenance/manual_upgrade.html vorher habe ich die updatepakete hier heruntergeladen: https://owncloud.org/changelog/ genauer: https://download.owncloud.org/community/owncloud-8.2.7.zip https://download.owncloud.org/community/owncloud-9.0.4.zip https://download.owncloud.org/community/owncloud-9.1.0.zip Danach habe ich dann auch das Update von 9.04 auf 9.1 gemacht: das lief ebenso unproblematisch durch, allerdings konnten sich danach keine LDAP Nutzer mehr anmelden. Die owncloud verursachte über Stunden (von 3 Uhr Nachts bis Morgends um 7:30 Uhr) Vollast auf mehreren Kernen. Ich habe jeden "Test" Knopf in den LDAP Einstellungen befragt: alle sagen, dass es alles funktioniert. Ebenso habe ich per telnet versucht den LDAP zu erreichen: geht auch. Danach hab ich wieder das Backup eingespielt und alles nochmal versucht: gleicher Effekt -> wieder Backup zurückgespielt (ich liebe rsync) Heute Nacht hab ich also nochmal das Update auf 8.27 und 9.04 gemacht und das ganze dabei belassen. Suche nach owncloud update 9.1 ldap problem ergab nichts Sinnvolles: jetzt hänge ich da also erst mal. Nächste Woche mache ich in meiner Schule mal das UPdate von 9.04 auf 9.1: Vielleicht liegt es ja an der Installation im Seminar .. ich habe bei früheren update-Problemen schon mal folgenden Weg erfolgreich umgesetzt: https://doc.owncloud.org/server/9.0/admin_manual/maintenance/upgrade.html und zwar den Vorschlag: "Manually upgrading is also an option for users on shared hosting; download and unpack the ownCloud tarball to your PC. Delete your existing ownCloud files, except data/ and config/ files, on your hosting account. Then transfer the new ownCloud files to your hosting account, again preserving your existing data/ and config/ files." Nach dem Entpacken der owncloud-Pakete müssen noch die Rechte geändert werden: chown -R www-data:www-data /var/www/owncloud/ Das hat funktioniert, ich musste lediglich die Apps aktivieren, was nicht weiter schlimm war, da die Anzahl überschaubar ist. Dieses Verfahren habe ich allerdings beim update von 9.0.1 auf 9.0.2 angewendet. Ob es dieses Mal hilft, weiß ich (noch) nicht. Viele Grüße Wilfried ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] owncloud update
Moin, ich hänge mich mal hier dran. Ich habe das Update auch angestoßen (von 9.02 auf 9.1). Allerdings brach es bei mir ab mit einer Fehlermeldung, dass der LDAP nicht zu erreichen sei. Ein Zugriff auf die Admin-Seite ging nicht, da gemeldet wurde, dass ein Update eingespielt werden müsse. Dieses brach aber wegen des LDAP ab, Ich habe also die LDAP-App mittels sudo -u www-data php occ app:disable user_ldap deaktiviert . Daraufhin lief das Update ohne Probleme durch. Dann die App wieder aktiviert. Allerdings ist eine Benutzeranmeldung nun nicht mehr möglich. Nur der lokale Admin kann sich anmelden. Die LDAP-Konfiguration wird auf der Admin-Seite als in Ordnung beschrieben. Ein Test der Konfiguration liefert ebenfalls ein positives Ergebnis. Teste ich die LDAP-Konfiguration aber auf der Konsole mit sudo -u www-data php occ ldao:test-config s01 bekomme ich die Fehlermeldung, dass eine Verbindung zum LDAP-Server nicht hergestellt werden kann. Ich bin einigermaßen ratlos. Vielleicht hat ja einer der Herren einen Tipp. Gruß christian Am 22.07.2016 um 14:49 schrieb Wilfried Larisch: Hallo Owncloudnutzer, nachdem im Administrationsbereich als stable die Version 9.0.4 erschienen ist, habe ich dort das update von 9.0.2 aus angestoßen. Es lief zwar fix und laut Meldungen fehlerlos durch, allerdings konnte ich mich danach zwar noch anmelden, aber dann kam eine apache-Fehlermeldung den Port 443 betreffend und sonst nix mehr. Da ich nicht lange suchen wollte, habe ich ein Backup des Owncloudservers zurückgespielt. Im Owncloudforum habe ich dazu nichts gefunden. Sobald ich Zeit (und Lust) habe, werde ich das 'Manually upgrading" mit dem tar-Archiv probieren. Viele Grüße Wilfried ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] OT: Linux-Clients! Lehrerverständliche Argumentationshilfen für eine reine Linux-Client-Lösung gesucht
Hallo zusammen, wir haben vor ein paar Jahren schon die Lehrerrechner auf Ubuntu-Clients umgestellt. So haben also alle Kollegen, die wollen, auch schon Erfahrung damit sammeln können. So war auch der Umstieg in den Computerräumen nicht so groß. Das geschah ohne vorher ein Votum der GLK einzuholen. Und das bewusst. Wenn den Kollegen das Thema so wichtig ist, werden sie irgendwann in einer GLK einen entsprechenden Antrag stellen. Dann wird diskutiert und man wird alle bekannten Argumente anführen können, die für die Ubuntu-Clients sprechen. Aber erst dann. In einem Computerraum stelle ich neben dem Ubuntu-Client noch ein altes XP zur Verfügung, damit vor allem die Mathekollegen ihre so unverzichtbare Software benutzen können (bald wird das durch den Leoclient ersetzt). Auf diesem XP ist auch noch ein uraltes Office, frag mich nicht, welches. Aber das benutzt kaum noch einer. Außerdem habe ich die neuen relativ neuen Laserdrucker nur unter Ubuntu verfügbar gemacht, sodass die meisten Kollegen nun eben Ubuntu verwenden (ok, das ist ein biss unfair). Ich habe auch "Fortbildungen" angeboten, die aber, wie nicht anders zu erwarten, kaum besucht wurden. Schulbuchspezifische Software wird bei und kaum benutzt, zumindest möchte keiner, dass ich sie installiere, die meisten greifen auf irgendwelche Online-Angebote zurück. Insgesamt habe ich dieses Jahre 2 Programme installiert ( eine Videoschnittprogramm, ohne das der Kollege nicht leben zu können glaubte, sowie eines für den Informatikkurs). Und von beiden gab es eine Linuxvariante, also kein Problem. Wenn die Kollegen lange genug Zeit haben, mit den Ubuntu-Clients zu arbeiten, erkennen sie auch die auf der Hand liegenden Vorteile. Manche Kritiker verwenden es mittlerweile sogar bewussst absichtlich, da sie auf italc nicht verzichten wollen und bemerkt haben, dass Epoptes viel besser funktioniert. Gruß ch Am 13.05.2016 um 08:39 schrieb Holger Baumhof: Hallo, Ich freue mich auf Antworten/Anregungen/Hilfen/Kommentare. Ich habe das auch hinter mir ... während einer Fortbildung vor ein paar Jahren hatte ich seinerzeit eine "kleine" Präsentation gezeigt, in der z.B. Kosten abgewägt werden und auch sonst viele gute Argumente pro Linux aufgezählt werden. Das könnte ich dir schicken, falls du Interesse daran hast. Ansonsten gibt's auch einen Beitrag dazu auf unserer HP: http://www.leoninum.org/2014/03/linux/ was inzwischen auch helfen kann ist wenn man die Zahlen richtig rückt. Oft kommt das Argument, dass ja "alle" Windwos haben und "jeder" MS Office sowiso schon hat. Dann weise ich gerne auf diese Verlautbarung von Microsoft aus dem Jahre 2014 hin: https://redmondmag.com/articles/2014/07/14/windows-use-at-14-percent.aspx Windows läuft nur auf 14% aller Rechner .. wenn man Telefone und Tablets mitzählt... Man muss also eher sagen: "alle" verwenden schon linux oder BSD: nämlich in ihren Smartphones... Da hat es jeder geschafft sich mit einer anderen GUI an zu freunden, aber am Desktop geht das nicht? Kleine Anekdote zum Artikel von Microsoft: "damals" war ihre Strategie, dass sie innerhalb von 4 Jahren 10% Marktanteil bei mobilen Geräten bekommen. Inzwischen haben sie das mehr oder weniger aufgegeben: Windows Phones soll es nurnoch für Enthusiasten geben: keine LowCost Dinger mehr. Dabei waren die kleinen Luminas wirklich günstig und gar nicht so schlecht ausgestattet: diese Subvention konnte sich aber selbst Microsoft nicht lange leisten. Viele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Keine Ldapabfrage nach Migration auf lml 6.1
Hallo, danke für die Anworten, den Port in der Quelle habe ich entfernt -> keine Änderung Die Ip des Belwü-Servers, auf dem das Portfolio liegt ist in /etc/ldap/slapd.conf im Abschnitt "Limited Access" so eingetragen: "by anonymous peername.ip=BelwueIP auth" keine Änderung. gruß chris Am 08.06.2015 um 22:51 schrieb Holger Baumhof: Hallo Chris, ich hoffe, Ihr hattet erholsame Ferien. Ich habe in den Ferien festgestellt, dass die Ldap-Abfrage an unserem Schulportfolio, das bei Belwue liegt scheitert. Ist mir bisher nicht aufgefallen, da ich der selten drauf zugreife (seit der Migration offenbar noch nicht. Auch den Kollegen scheint das nicht aufgefallen zu sein. Wie auch immer. Die Anmeldung scheitert. Die lokale Anmeldung funktioniert und dort sehe ich die Fehlermeldung: 1. LDAP: couldn't connect to LDAP server 2. LDAP: can not bind anonymously Der Ldap läuft aber und funktioniert auch, denke ich, denn Ein telnet IP-rotes-Interface 636 ergibt Trying Rotes Interface... Connected to Rotes Interface. Escape character is '^]'. Ein netstat -l | grep ldap am Server ergibt tcp0 0 *:ldaps *:* LISTEN tcp0 0 *:ldap *:* LISTEN Eine Firewallregel habe ich auch angelegt: Protokoll: TCP Quelle: 129.143.0.0/16:636 Ziel: Firewall (ROT): 636 -> 10.16.1.1:636 Die local.php ist unverändert, da sich beim servername und bei den Domännamen nichts geändert hat. Vor der Migration ging es. Ist irgendeine Datei nicht migriert worden? Wo könnte ich ansetzen? steht die IP des BelWü Servers noch in der /etc/ldap/slapd.conf ? Viele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
[lmn] Keine Ldapabfrage nach Migration auf lml 6.1
Hallo zusammen, ich hoffe, Ihr hattet erholsame Ferien. Ich habe in den Ferien festgestellt, dass die Ldap-Abfrage an unserem Schulportfolio, das bei Belwue liegt scheitert. Ist mir bisher nicht aufgefallen, da ich der selten drauf zugreife (seit der Migration offenbar noch nicht. Auch den Kollegen scheint das nicht aufgefallen zu sein. Wie auch immer. Die Anmeldung scheitert. Die lokale Anmeldung funktioniert und dort sehe ich die Fehlermeldung: 1. LDAP: couldn't connect to LDAP server 2. LDAP: can not bind anonymously Der Ldap läuft aber und funktioniert auch, denke ich, denn Ein telnet IP-rotes-Interface 636 ergibt Trying Rotes Interface... Connected to Rotes Interface. Escape character is '^]'. Ein netstat -l | grep ldap am Server ergibt tcp0 0 *:ldaps *:* LISTEN tcp0 0 *:ldap *:* LISTEN Eine Firewallregel habe ich auch angelegt: Protokoll: TCP Quelle: 129.143.0.0/16:636 Ziel: Firewall (ROT): 636 -> 10.16.1.1:636 Die local.php ist unverändert, da sich beim servername und bei den Domännamen nichts geändert hat. Vor der Migration ging es. Ist irgendeine Datei nicht migriert worden? Wo könnte ich ansetzen? gruß chris ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo zusammen, danke für die Hinweise. Mittlerweile habe ich es doch noch hinbekommen. Woran es gelegen hat, kann ich allerdings nicht genau eingrenzen, da ich einige Änderungen auf einmal durchgeführt habe. Ich habe das vorhandene virtuelle Netz gelöscht und ein neues angelegt, dann in der XMl-Datei, die das Netz definiert darauf geachtet, dass keine Dopplungen von MAC-Adressen oder IPs vorkamen und auf einmal lief es dann. Danke für Mitdenken gruß chris Am 11.05.2015 um 20:05 schrieb Steffen Auer: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Chris, Am 08.05.2015 um 10:05 schrieb Chris Hubber: @Michael danke für das Angebot, aber ich glaube, dass das nicht funktioniert. Zumindest hat es mir google so mitgeteilt, als ich vorhin, allerdings nur recht oberflächlich, danach gesucht habe, ob Proxmox-Vms unter kvm laufen. Werde das am Nachmittag mal genauer recherchieren. eigentlich ist aber beides KVM. Sollte also eigentlich gehen, vielleicht mit ein wenig Vorarbeit an der VM-Datei... Viele Grüße Steffen - -- Wir sind nicht nur nett, wir sind sogar linuxmuster.net Mein System: - - virtualisiert mit Proxmox 3.4 - - linuxmuster.net 6.0 - - IPFire 2.17 - - Linbo 2.1.10-0 - - Ubuntu 12.04-Client - - Erweiterungen: Chillispot, Pykota, MRBS und OpenSchulportfolio - - Moodle extern (Belwue) per ldaps angebunden Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. - Diese E-Mail ist mit OpenPGP signiert. Der öffentliche Schlüssel zur Überprüfung der Signatur ist hier hinterlegt: pool.sks-keyservers.net - -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVUO9qAAoJEBhc6lDKYVtJtY4IAMGJnN/Oe8G+O/avjEu+fbgd 7d5fJqGz8edq3RPwqKmzJbM2ksDT0ptxLDaqVTNiH2FtP6y7+0geyA5KOlt4B/G1 NoF+yQhO9hjAnaYuQbc5utPP2yAFwIV2qFsDd7ZBN76EcnC4bJuoUKUJRGhSXWk/ 93+OCu0YBrMBixb6od7v5LS5TOVbRCPXaGDV1S/uuieYOAm953DWFLL9WGrDykQN hGGiGFMK0jgOSK8zDsKhznR3q/8LXiQVeESupQSTpOnnmZo2+HyadmpCHVJsUq0Y OJgUAksF15dFOs+bUJJ11z0max6Z6EpRST2FAYDXBm4P7qhUNSqy0Mc/iZ5plRY= =bJg0 -END PGP SIGNATURE- ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo zusammen, in den letzten Tagen habe ich folgende Änderungen vorgenommen: Die Doppelung der MAC-Adressen beseitigt. reboot host > kein Erfolg (Ergebnis siehe weiter unten) Die IPs aus der /var/lib/libvirt/network/coova.xml entfernt. reboot host ---> kein Erfolg Dem coovanetz eine beliebige IP aus dem 172.16.16.0/24-Netz gegeben (nicht 172.16.16.1, 172.16.16.254 und auch nicht 172.16.16.3 (dem coova in seiner /etc/network/interfaces fest zugewiesen, da er vom IPfire keine bekommt) ---> nüscht Neues isoliertes Netz angelegt mit den bekannten Spezifikationen (172.16.16.0/24, kein dhcp, isoliertes netz) Libvirt vergibt jedesmal IP-Adressen. Die 172.16.16.1 dient als Gateway, wie ich gelesen habe. coova reboot. > auch nix Alle Firewallregeln für blau gelöscht, Änderungen bestätigt und alle wieder angelegt und die Änderungen bestätigt. ---> nix IP des coova (172.16.16.3) in die /etc/hosts des ipfire eingetragen Die IPs des servers und des ipfires (blau) in die /etc/hosts des coova eingetragen. Diese Anleitung ebenfalls eingearbeitet :http://www.linuxmuster.net/wiki/anwenderwiki:benutzerrechner:wlan:coovachilli-dns?s[]=coova&s[]=dns Als Ergebnis wie gehabt ping 172.16.16.254 --> destination host unreachable ping 172.16.16.1 ---> funktioniert telnet 10.16.1.1 636 --> unable to connect to remote host, connection refused Das bringt mich dazu, noch immer an ein Problem mit den Firewallregeln zu denken. Also zur Sicherheit Quelle BLAU ->Ziel 10.16.1.1Zielport 636Protokoll TCP Authentifizierung Quelle BLAU ->Ziel ROTZielport 53 Protokoll UDP DNS Quelle BLAU ->Ziel ROTZielport 800 Protokoll TCPProxy Die Regel Blau 53 -> Ziel Firewall BLAU 53 nimmt der IPfire nicht an. Die übrigen Einstellungen: Advanced Webproxy aktiviert auf blau, transparent auf blau Zugriff auf blau -> MAC der virtuellen eth0 des coova. Was ich noch nicht gemacht habe, ist es, den Host auf 14.04 upzudaten oder den IPfire von core 85 nach 87 zu bringen. Vielleicht hat ja einer noch ne Idee. Ich hab keine mehr. Wahrscheinlich sehe ich den Wald vor lauter Bäumen nicht mehr. Danke für Mitdenken gruß chris Am 05.05.2015 um 09:10 schrieb Holger Baumhof: Hallo Christian, Was mir noch aufgefallen ist, ist die Tatsache, dass meine virbr1 die gleiche MAC-Adresse hat wie eines der vnets. Ob das so sein muss, konnte ich noch nicht feststellen. es dürfen nie zwei Netzwerkgeräte die selbe MAC haben. Das mußt du ändern. VIele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Moin Christian, danke für die Mail. Die Anleitung bzgl. der Anpassung des Coova-DNS hatte ich vergessen abzuarbeiten. Nachdem dies geschehen ist, bekomme ich immerhin ein "host unreachable" und bei telnet 10.16.1.1 636 ein "no route to host". Was mir noch aufgefallen ist, ist die Tatsache, dass meine virbr1 die gleiche MAC-Adresse hat wie eines der vnets. Ob das so sein muss, konnte ich noch nicht feststellen. Deinen Vorschlag mit der freien IP konnte ich noch nicht testen, da ich im Moment den Host nicht rebooten möchte. gruß ch Am 03.05.2015 um 13:34 schrieb Christian Weichhard: Hallo Chris, nochmal neue Gedanken zu diesem Problem: der Start dauert bei mir auch lange, die Boot-Meldungen hängen bei "Starting Chilli ..." aber am Ende klappt es mit der IP. Der DHCP des IPFire gibt dem Coova die fest vorgegebene Adresse, bei mir x.x.x.2, das klappt. Der DHCP vergibt meinem coova keine IP und schon gar nicht die von mir fest zugeschriebene 172.16.16.3. Lasse ich den dhcp machen, so wartet coova bei Boot ewig auf die Netzwerkkonfiguration und macht dann weiter, ohne der blauen Karte eine IP zugewiesen zu haben Der Host mischt sich in die Netzwerkkonfiguration ein, in der Datei /etc/libvirt/qemu/networks/coovaipfire.xml (auf dem Host) vergibt/vergab meiner der virbr1 eine IP-Adresse und zwar dieselbe wie dem IPFire. Da ich nicht herausgefunden habe, wie man das verhindert, habe ich in der oben beschriebenen Datei eine unbelegte IP-Adresse aus diesem Netz eingetragen. Nach einem Neustart des Host und der virtuellen Maschinen hängt Coova nicht mehr bei "Starting Chilli ...". Vielleicht hängt es bei dir auch an dieser Stelle. Schöne Grüße Christian ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo Christian, ups, da hätte ich beinahe deine Mail übersehen. Sorry. Die Idee, der blauen eth0 manuell die richtige IP zu verpassen, habe ich schon versucht. Das bringt immerhin insofern eine Verbesserung, als ein Ping nach 172.16.16.1 möglich ist. Das ist die IP der virbr1. Ich benutze hier virt-manager und die Netzwerkkarten sehen so aus wie bei dir. Ich denke auch, dass etwas mit der Virtualisierung nicht stimmt. Habe mal das Vereichnis /var/lib/libvirt/dnsmasq auf dem Host mit dem bei mir zuhause verglichen und ich habe festgestellt, dass auf dem Host die des virtuellen Netzes (coovanetz) fehlen z.B. coovanetz.conf, coovanetz.addnhosts, coovanetz.hostsfile, coovafile.leases. Die sollten doch eigentlich automatisch erstellt worden sein, denke ich, oder? Warum die fehlen, keine Ahnung. Wenn ich nächste Woche wieder in der Schule bin, werde ich dem mal nachgehen. Danke für die Unterstützung und allen einen schönen und erholsamen Feiertag gruß ch Am 28.04.2015 um 19:24 schrieb Christian Weichhard: Hallo Chris, die Netzwerkkonfiguration des Coova ist nicht in Ordnung. Verwaltest du deine Virtualisierung mit virt-manager? Darin hat bei mir und bei dir sicher auch der Coova zwei Netzwerkkarten 1. Virtuelles Netzwerk 'coovaipfire': Isoliertes Netzwerk, nur internes und Host-Routing -> BLAU 2. Bridge br2 (Host device em3) -> durchsichtig Mit dem blauen Netz passt etwas nicht, vielleicht liegt es an der Virtualisierung. Falls nicht, könntest du noch versuchen, dem coova auf blau diese Adresse zuzuweisen. Auf dem coova "ifconfig eth0 172.16.16.x" weiterhin viel Glück Christian ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo zusammen, das Wlan ist noch immer bockig, aber der Tipp mit der Änderung in /etc/default/grub hat das Problem der hängenden Ausgabe in Virtmanager beseitigt. Danke für den Hinweis- Gruß ch Am 22.04.2015 um 22:26 schrieb Uwe Seckinger, Sven Röhrauer: Hallo Chris, wegen der hängenden Anzeige im Virtmanager probier mal folgendes: In /etc/default/grub die Zeile #GRUB_GFXMODE=640x480 ändern in GRUB_GFXMODE=text und folgende Zeile ergänzen: GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT abschließen mit sudo update-grub2 Grüße, Sven On Wed, 22 Apr 2015 17:34:41 +0200 "Chris Hubber" wrote: Hi,wollte nur noch kurz rückmelden, dass der client pc nun eine korrekte IP bekommt (192.168.0.14). Der Aufruf einer beliebigen http: Seite führt nicht zur Weiterleitung auf die Coova-Seite. Rufe ich die aber direkt auf (192.168.0.1:3990) erscheint sie, allerdings ist keine Anmeldung möglich. D.h. es stimmt wohl noch immer was mit den Firewallregeln nicht. Seltsam ist allerdings, dass die Anzeige der VM im virtmanager allerdings während des boots der Vm stehen geblieben ist und ich keine neue konsole öffnen kann, das die Annahme der "Taste senden" Kommandos nicht klappt. Die Vm läuft aber offensichtlich..gruß ch Gesendet: Mittwoch, 22. April 2015 um 15:46 Uhr Von: "Chris Hubber" An: linuxmuster-user@lists.linuxmuster.net Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM Hallo Holger,wir haben lml 6.1 Ipfire-Version Core 85 Die Regeln habe ich gelöscht und wieder neu angelegt. Leider noch immer kein Fortschritt. Ich bin ziemlich ratlos. Im Moment bekommen weder die virtuelle Karte noch die br2 eine IP zugewiesen. MAC-Adresse der virtuellen Karte ist im IPfire eingetragen. Zugriff auf blau aktiviert, DHCP für blaues interface an, alles soweit Standard. Kein Ping nach nirgends, (so nenne ich meinen ersten Roman :-) ) network unreachable.Dafür ist ein neues Phänomen aufgetaucht, nachdem ich den coova neu installiert habe. Beim Boot bleibt die Anzeige des Coova bei "fsck from util-linux 2.20.2 /dev/vda1: sauber, 58944/24 Dateien ..." hängen, die vm läuft aber scheinbar weiter. Es ist was faul im Staate DänemarkGruß ch Gesendet: Mittwoch, 22. April 2015 um 14:51 Uhr Von: "Holger Baumhof" An: "Discussions about using linuxmuster.net" Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM Hallo Chris, > Das ist die gute Nachricht! Allerdings indem ich eth0 (farblos) an br1, also das > grüne Netz gehängt habe. Im blauen Netz tut sich nach wie vor nichts. welche lml Version habt ihr? Welche Version des IPFire? Das steht im Webfrontend unter Packfire Da sollte Core 86 oder so stehen. Ich würde die Regeln für den coova in der Firewalld es IPFire mal löschen, speichern und neu anlegen, Speichern. > Ich poste hier mal den Inhalt der Datei, evt. kann je einer einen Fehler entdecken. > /var/lib/libvirt/network/coovanetz.xml > [...] > > coovanetz > f74f4af2-66b1-cc1e-1fad-218636d20c27 > name=9virbr19 stp=9on9 delay=909 /> > address=952:54:00:9f:B2:DE9/> > netmask=9255.255.255.09> > > das sieht bei mir fast genau so aus: coovanetz 734aec40-0b92-4707-9921-2b9540614de2 name=9virbr19 stp=9on9 delay=909/> Viele Grüße Holger > Gruß ch > *Gesendet:* Montag, 20. April 2015 um 23:01 Uhr > *Von:* "Holger Baumhof" > *An:* "Discussions about using linuxmuster.net" > > *Betreff:* Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM > Hallo Christian, > > > Hallo Holger, Ja genau auf die Anleitung beziehe ich mich.Das virtuelle > interne Netz für coova habe ich via virtmanager erstellt, ansonsten br0, br1 und > br2 gemäß der Anleitung. Ich glaube auch, dass die Einrichtung des virtuellen > Netzes für den coova mein Problem ist. Ich habe 12.04 auf dem Host laufen. > > ich hab inzwischen alle meine KVM Hosts auf 14.04 upgedatet: Vorsicht: > den Host, nicht den lml server. > Das ging überall ohne Probleme. > Ich schick dir gleich einen screenshot mit meinen Einstellungen des vSwitches. > > 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 > > > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > -- 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 ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo Holger, Ja genau auf die Anleitung beziehe ich mich.Das virtuelle interne Netz für coova habe ich via virtmanager erstellt, ansonsten br0, br1 und br2 gemäß der Anleitung. Ich glaube auch, dass die Einrichtung des virtuellen Netzes für den coova mein Problem ist. Ich habe 12.04 auf dem Host laufen. Gruß christian Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Holger Baumhof Datum: 20.04.2015 21:28 (GMT+01:00) An: "Discussions about using linuxmuster.net" Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM Hallo Christian, > ja, nur den Coova, dachte ich. > Ich verwende KVM und bin dabei streng nach der im Wiki stehenden > Referenzvirtualisierung mit KVM nach gegangen. > Seltsam eigentlich .. eigentlich nicht. Ich nehme an, du beziehst dich auf die INstallation der lml unter KVM auf einem Ubuntu 12.04 64bit server: die habe ich geschrieben: genau so habe ich mittlerweile 5 Server aufgesetzt. Da steht aber nicht drin, wie man das Netz für den coova einrichtet. Was hast du den drunter? 12.04 oder 14.04? Falls du 14.04 hast, dann kannst du das Netz mittels virtmanager vom eigenen Rechner aus anlegen. So habe ich das gemacht. Wie hast du das virtuelle interne Netz erstellt? 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 ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo Holger, ja, nur den Coova, dachte ich. Ich verwende KVM und bin dabei streng nach der im Wiki stehenden Referenzvirtualisierung mit KVM nach gegangen. Seltsam eigentlich gruß christian Am 20.04.2015 um 19:47 schrieb Holger Baumhof: Hallo Christian, ok, werd ich machen. Mal schauen, ob ich was finde. Im Moment bin ich kurz, einfach die Sache neu zu installieren. So viel wie ich da schon rumgepfuscht habe, ist das vielleicht der einfachere Weg :-) meinst du nur den coova? Das kannst du machen: ich denke aber bisher nicht, dass das viel bringen wird: das Problem scheint ja eher am virtuellen Switch zu hängen. Wie hast du den eingerichtet? Ist das KVM oder PRoxmoxx? VIele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hallo Holger, ok, werd ich machen. Mal schauen, ob ich was finde. Im Moment bin ich kurz, einfach die Sache neu zu installieren. So viel wie ich da schon rumgepfuscht habe, ist das vielleicht der einfachere Weg :-) gruß christian Am 20.04.2015 um 16:23 schrieb Holger Baumhof: Hallo Christian, habe die IP im dhcp-server des ipfire fest zugeordnet. Nach einem reboot bekomme ich aber gar keine IPs mehr. Irgendwas ist da völlig durcheinander geraten da stimmt irgend was mit deinem virtuellen Switch nicht. Such mal in der Richtung. Viele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
ion.
HS_UAMSERVER=$HS_UAMLISTEN
# Use HS_UAMFORMAT to define the actual captive portal url.
# Shell variable replacement takes place when evaluated, so here
# HS_UAMSERVER is escand and later replaced by the pre-defined
# HS_UAMSERVER to form the actual "--uamserver" option in chilli.
HS_UAMFORMAT=http://\$HSUAMLISTEN:\$UAMUIPORT/www/login.chi
# Same principal goes for HS_UAMHOMEPAGE.
HS_UAMHOMEPAGE=http://\$HS_UAMLISTEN:\$HS_UAMPORT/www/coova.html
###
##
Standard configurations
##
HS_MODE=hotspot
HS_TYPE=chillispot
#
Directory specifying where internal web pages can be served
#
by chilli with url /www/. Only extensions like .html
#
.jpg, .gif, .png, .js are allowed. See below for using .chi as a
#
CGI extension.
HS_WWWDIR=/etc/chilli/www
# Using this option assumes 'haserl' is installed per-default
# but, and CGI type programm can ran from wwwsh to process requests
# to chille with url /www/filename.chi
HS_WWWBIN=/etc/chilli/wwwsh
#
Some configurations used in certain user interfaces
HS_PROVIDER=Coova
HS_PROVIDER_LINK=http://www.linuxmuster.net
# Wenn im Radius kein Session Timeout definiert wurde,
# wann fliegt der Hotspot User wieder raus (auch mitten
# im Surfen!)
HS_DEFSESSIONTIMEOUT=0 # In Sekunden
# # Wenn nichts passiert, wann fliegt der Hotspot User raus
HS_DEFIDLETIMEOUT=900 # In Sekunden
###
## WISPr RADIUS Attribute support
HS_LOC_NAME="CopGym WiFi"
# WISPr Location Name and used in portal
###
# setting radius auth type to pap
HS_RAD_PRTOT="pap"
--
/etc/chilli/main.conf:
# THIS FILE IS AUTOMATICALLY GENERATED
cmdsocket
/var/run/chilli.eth1.sock
unixipc
chilli.eth1.ipc
pidfile
/var/run/chilli.eth1.pid
net
192.168.0.0/255.255.0.0
uamlisten
192.168.0.1
uamport
3990
dhcpif
eth1
aumallowed
",192.168.0.1,www.copernicus-gymnasium.de,www.linuxmuster.net"
uamanydns
uid "108"
gid "115"
domain "lan"
dns1 "172.16.16.254"
dns2 "8.8.8.8"
uamhomepage://192.168.0.1:3990/www/coova.html
wwwdir /etc/chilli/www
wwwbin /etc/chilli/wwwsh
uamuiport 4990
locationname "CopGym WiFi"
radiuslocationname "CopGym WiFi"
radiuslocationid "isocc=,cc=,ac=,network=Coova,"
Viele Grüße
Holger
Danke für die Mühe
Gruß christian
Am 18.04.2015 um 12:56 schrieb Christian Huber:
Moin zusammen, Ich ringe noch immer mit dem Coova.Habe festgestellt, dass der apache auf dem coova probleme mit der namensauflösung hatte. Ein Blick in /etc/hosts hat gezeigt, dass dort 127.16.16.254 stand statt 172.16.16.254.Seitdem ich das geändert habe, kann ich von einem TestClient diese IP auch anpingen und ein hostname --fqdn auf dem coova ergibt auch ein korrektes Ergebnis.Das an br2 ("farbloses Netz") angeschlossene Laptop bekommt allerdings eine IP aus dem 172.16.16.x Netz. Das ist doch aber das eigentlich blaue Netz, in dem nur der coova hängen sollte. Das Laptop kommt nicht ins Netz (ich habe auch keine https-adresse genommen), die Coova-Seite erscheint nicht.Irgendwie ist noch immer noch der Wurm drin.Vielleicht hat einer von euch noch einen Tipp?
Gruß christian huber
Von meinem Samsung Gerät gesendet.
Ursprüngliche Nachricht
Von: Christian Huber
Datum: 17.04.2015 15:14 (GMT+01:00)
An: "Discussions about using linuxmuster.net"
Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi,danke für die Antwort. Aber hier tut sich nix. Das angeschlossene Laptop bekommt eine IP, das wars dann schon. Vom coova aus geht auch kein ping 172.16.16.254. Versuche nun alle anderen möglichen Konfigurationen der blauen NIC. Geht das nicht, erstelle ich die Ipfire-regeln neu. Geht das nicht, entferne ich das linuxmuster-chilli Paket und installiere es neu und fange nochmal von vorne an...Geht das auch nicht, keine Ahnung...
Gruß vom frustrierten ch
Von meinem Samsung Gerät gesendet.
Ursprüngliche Nachricht
Von: Michael Hagedorn
Datum: 17.04.2015 14:07 (GMT+01:00)
An: linuxmuster-user@lists.linuxmuster.net
Betreff: Re: [lmn]
Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi.
Leider gelingt es nicht, vom coova aus server oder v.a. ipfire anzupingen.
Mir auch nicht ... es klappt lediglich:
ping 172.16.16.254 (also BLAU vom IPFire)
ping ins grüne Netz geht nicht. Das Problem habe ich aber momentan auch
(s. anderer Thread)
Der Chillispot regelt aber den Rest selbst. Du musst einfach mal
versuchen, dich mit einem Laptop in das WLAN-Netz zu klinken. Wenn du
dann irgendeine Seite (nicht https!) aufrufst, sollte eine Weiterleitung
zur Anmeldeseite "coova" erscheinen. Wenn du dich erfolgreich anmelden
konnest, kannst du danach surfen.
Bei mir gelange ich auch unter dieser Adresse zur Anmeldung:
http://172.11.0.1:4990 (oder auch :3990 -- der Unterschied ist mir nicht
ganz klar)
Übrigens noch eine Anmerkung: Eigentlich soll man ja
http://logout/ ei
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Moin zusammen, Ich ringe noch immer mit dem Coova.Habe festgestellt, dass der
apache auf dem coova probleme mit der namensauflösung hatte. Ein Blick in
/etc/hosts hat gezeigt, dass dort 127.16.16.254 stand statt
172.16.16.254.Seitdem ich das geändert habe, kann ich von einem TestClient
diese IP auch anpingen und ein hostname --fqdn auf dem coova ergibt auch ein
korrektes Ergebnis.Das an br2 ("farbloses Netz") angeschlossene Laptop bekommt
allerdings eine IP aus dem 172.16.16.x Netz. Das ist doch aber das eigentlich
blaue Netz, in dem nur der coova hängen sollte. Das Laptop kommt nicht ins Netz
(ich habe auch keine https-adresse genommen), die Coova-Seite erscheint
nicht.Irgendwie ist noch immer noch der Wurm drin.Vielleicht hat einer von euch
noch einen Tipp?
Gruß christian huber
Von meinem Samsung Gerät gesendet.
Ursprüngliche Nachricht
Von: Christian Huber
Datum: 17.04.2015 15:14 (GMT+01:00)
An: "Discussions about using linuxmuster.net"
Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter
KVM
Hi,danke für die Antwort. Aber hier tut sich nix. Das angeschlossene Laptop
bekommt eine IP, das wars dann schon. Vom coova aus geht auch kein ping
172.16.16.254. Versuche nun alle anderen möglichen Konfigurationen der blauen
NIC. Geht das nicht, erstelle ich die Ipfire-regeln neu. Geht das nicht,
entferne ich das linuxmuster-chilli Paket und installiere es neu und fange
nochmal von vorne an...Geht das auch nicht, keine Ahnung...
Gruß vom frustrierten ch
Von meinem Samsung Gerät gesendet.
Ursprüngliche Nachricht
Von: Michael Hagedorn
Datum: 17.04.2015 14:07 (GMT+01:00)
An: linuxmuster-user@lists.linuxmuster.net
Betreff: Re: [lmn]
Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi.
> Leider gelingt es nicht, vom coova aus server oder v.a. ipfire anzupingen.
Mir auch nicht ... es klappt lediglich:
ping 172.16.16.254 (also BLAU vom IPFire)
ping ins grüne Netz geht nicht. Das Problem habe ich aber momentan auch
(s. anderer Thread)
Der Chillispot regelt aber den Rest selbst. Du musst einfach mal
versuchen, dich mit einem Laptop in das WLAN-Netz zu klinken. Wenn du
dann irgendeine Seite (nicht https!) aufrufst, sollte eine Weiterleitung
zur Anmeldeseite "coova" erscheinen. Wenn du dich erfolgreich anmelden
konnest, kannst du danach surfen.
Bei mir gelange ich auch unter dieser Adresse zur Anmeldung:
http://172.11.0.1:4990 (oder auch :3990 -- der Unterschied ist mir nicht
ganz klar)
Übrigens noch eine Anmerkung: Eigentlich soll man ja
http://logout/ eintippen, wenn man sich wieder abmelden will. Das klappt
hier nicht (mehr), da der Firefox daraus (neuerdings?) eine Adresse im
Internet macht, anstatt lokal zu suchen. Bei Euch auch?
hth,
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 (extern mit LDAPS und openLML-Modul)
___
linuxmuster-user mailing list
linuxmuster-user@lists.linuxmuster.net
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
___
linuxmuster-user mailing list
linuxmuster-user@lists.linuxmuster.net
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi,danke für die Antwort. Aber hier tut sich nix. Das angeschlossene Laptop bekommt eine IP, das wars dann schon. Vom coova aus geht auch kein ping 172.16.16.254. Versuche nun alle anderen möglichen Konfigurationen der blauen NIC. Geht das nicht, erstelle ich die Ipfire-regeln neu. Geht das nicht, entferne ich das linuxmuster-chilli Paket und installiere es neu und fange nochmal von vorne an...Geht das auch nicht, keine Ahnung... Gruß vom frustrierten ch Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Michael Hagedorn Datum: 17.04.2015 14:07 (GMT+01:00) An: linuxmuster-user@lists.linuxmuster.net Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM Hi. > Leider gelingt es nicht, vom coova aus server oder v.a. ipfire anzupingen. Mir auch nicht ... es klappt lediglich: ping 172.16.16.254 (also BLAU vom IPFire) ping ins grüne Netz geht nicht. Das Problem habe ich aber momentan auch (s. anderer Thread) Der Chillispot regelt aber den Rest selbst. Du musst einfach mal versuchen, dich mit einem Laptop in das WLAN-Netz zu klinken. Wenn du dann irgendeine Seite (nicht https!) aufrufst, sollte eine Weiterleitung zur Anmeldeseite "coova" erscheinen. Wenn du dich erfolgreich anmelden konnest, kannst du danach surfen. Bei mir gelange ich auch unter dieser Adresse zur Anmeldung: http://172.11.0.1:4990 (oder auch :3990 -- der Unterschied ist mir nicht ganz klar) Übrigens noch eine Anmerkung: Eigentlich soll man ja http://logout/ eintippen, wenn man sich wieder abmelden will. Das klappt hier nicht (mehr), da der Firefox daraus (neuerdings?) eine Adresse im Internet macht, anstatt lokal zu suchen. Bei Euch auch? hth, 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 (extern mit LDAPS und openLML-Modul) ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Guten Morgen zusammen, ich habe heute versucht, die gestern gewonnenen Erkenntnisse umzusetzen.br2 ist nun mit dem Wlannetz verbunden, an dem testweise ein laptop hängt und für das blaue Netz habe ich in virt-manager ein virtuelles netz angelegt: 172.16.0.0/24, kein Dhcp als isoliertes Netzwerk . (Kann da der Fehler liegen?)Die Einstellungen am Ipfire sind nach der Anleitung erstellt.Leider gelingt es nicht, vom coova aus server oder v.a. ipfire anzupingen.Ich nehme an, dass der Fehler in der Konfiguration der blauen, rein virtuellen Karte, liegt. So langsam gehen mir die Ideen aus. Ich könnte blau auch als NAT oder geroutet konfigurieren, aber dann bin ich echt mit meinem Latein am Ende.Vielleicht hat noch einer der Herren eine Idee. Gruß christian Huber Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Christian Huber Datum: 16.04.2015 22:23 (GMT+01:00) An: linuxmuster-user@lists.linuxmuster.net Betreff: Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM Hi, ja genau. Das heißt dann aber, dass ich meine br2 an das farblose NIC hängen muss, da hier die Verbindung zur realen Hardware stattfindet. Für Blau brauche ich demnach einen neuen rein virtuellen Switch. Dann lag mein Fehler darin, dass ich fälschlicherweise glaubte, Blau bekäme br2. Ich werde das morgen ausprobieren, wenn ich das erledigt habe, wofür man mich eigentlich bezahlt: Unterricht!! Vielen Dank Michael gruß christian huber Am 16.04.2015 um 21:58 schrieb Michael Hagedorn: > Hi. > Ich glaube ich weiß, was dein Problem ist: ich habe unter Proxmox für > BLAU den virt. Switch vmbr2 erstellt. Daran hängen die Geräte für BLAU - > doch dieser Switch ist unter Proxmox mit keiner echten NIC verbunden. Es > ist rein virtuell. NUR das andere "farblose" NIC wird mit "echter > Hardware" verbunden. Dort hängt zur Zeit unser LinkSys-AP, der nun > Verstärkung von den Unifi-APs bekommt. Das funktioniert im Moment ganz > gut. Seitdem ich nun die Controller-Software ebenfalls im "farblosen" > WLAN-Netz laufen habe, klappt es. > Vielleicht bringt das ja nochmal Licht ins Dunkel?? > > Michael > > > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi, ja genau. Das heißt dann aber, dass ich meine br2 an das farblose NIC hängen muss, da hier die Verbindung zur realen Hardware stattfindet. Für Blau brauche ich demnach einen neuen rein virtuellen Switch. Dann lag mein Fehler darin, dass ich fälschlicherweise glaubte, Blau bekäme br2. Ich werde das morgen ausprobieren, wenn ich das erledigt habe, wofür man mich eigentlich bezahlt: Unterricht!! Vielen Dank Michael gruß christian huber Am 16.04.2015 um 21:58 schrieb Michael Hagedorn: Hi. Ich glaube ich weiß, was dein Problem ist: ich habe unter Proxmox für BLAU den virt. Switch vmbr2 erstellt. Daran hängen die Geräte für BLAU - doch dieser Switch ist unter Proxmox mit keiner echten NIC verbunden. Es ist rein virtuell. NUR das andere "farblose" NIC wird mit "echter Hardware" verbunden. Dort hängt zur Zeit unser LinkSys-AP, der nun Verstärkung von den Unifi-APs bekommt. Das funktioniert im Moment ganz gut. Seitdem ich nun die Controller-Software ebenfalls im "farblosen" WLAN-Netz laufen habe, klappt es. Vielleicht bringt das ja nochmal Licht ins Dunkel?? Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Hi Michael,
ja ein wenig. Danke sehr. Aber es bleiben noch immer ein paar Fragen.
Vielleicht bin ich auch einfach zu beschränkt...
Ok, 2 Nics. Von drei habe ich nur in Bezug auf die im Wiki stehende
Anleitung einer Referenzvirtualisierung mit KVM gesprochen, da habe ich
mich wohl unklar ausgedrückt. Sorry dafür!!!
Siehe
http://www.linuxmuster.net/wiki/dokumentation:handbuch:virtualisation:reference.kvm
Wenn die erste Nic im blauen Netz läuft, ist das nach meinem
Verständnis br2.
Wenn aber dort nur Nur der Chillispot läuft, wieso soll dann nach
Anleitung hier
http://www.linuxmuster.net/wiki/dokumentation:addons:linuxmuster-chillispot:chilliipfireconfig_blau
ein dhcp auf blau laufen?
Da könnte ich doch der NIC br2 einfach z.B. 172.16.16.1 geben und fertig.
Wenn der Chillispot die IPs der Wlanclients selbst vergibt und via tun0
mit dem blauen Interface (br2) kommuniziert, wieso zeigt dann br2 auf
eth2, von wo am Ende ein Kabel zu einem Switch geht, an dem die
AccesPoints hängen usw???
Und am Ende bleibt die Frage, welche Einstellung nehme ich im
virt-manager (KVM) oder händisch für die NIC des Dir von dir "farblos"
genannten Netzes vor? Hätte ich eine reale Maschine würde ich sie
einfach ignoireren, wie in der Anleitung beschrieben...
Puuh, und ich dachte Hölderlins Lyrik sei kompliziert... ;-)
Gruß ch
Am 16.04.2015 um 20:33 schrieb Michael Hagedorn:
Hi.
Ich bin einigermaßen verwirrt und für jeden Tipp dankbar. Wahrscheinlich
sehe ich den Wald vor lauter Bäumen nicht mehr.
Also ich benutze kein KVM aber evtl hilft es dir, wie ich es unter
Proxmox eingestellt habe: Es gibt im ChilliSpot tatsächlich zwei NICs
... davon läuft die eine im blauen Netz. Dort befindet sich aber NUR der
Chillispot und NUR dessen MAC muss auch im IPFire eingetragen werden.
Die andere NIC läuft in einem völlig getrennten Bereich (nennen wir das
mal WLAN-Netz ("ohne Farbe")) ... dorthin verbinden sich sämtliche
WLAN-Clients. IMHO sind also nur zwei und nicht drei virt. Devices
notwendig. Es ist deshalb verwirrend, weil der Chillispot selbst die
Verbindungen verwaltet und über ein zusätzliches Device (tun0) selbst
die IP-Adressen der WLAN-Clients vergibt. Die stammen aber nicht direkt
aus dem blauen Netz, sondern werden vom Chillispot selbst vergeben (bei
uns 172.11.0.x)
Jetzt klarer?
hth,
Michael
___
linuxmuster-user mailing list
linuxmuster-user@lists.linuxmuster.net
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
[lmn] Einstellungen für die zweite (?) Coova-Netzwerkarte unter KVM
Guten Abend zusammen, ich kämpfe ein bissl mit Coova, aber da muss wohl jeder durch :-) Jedenfalls habe ich versucht alle sachdienlichen Hinweise in Wiki und Liste zu beachten, aber im Moment bin ich völlig verwirrt. Ich fasse mal meinen Kenntnissstand kurz zusammen. Gemäß Referenzvirtualisierung mit KVM legt man auf dem drei virtuelle Brücken an, deren letzte, br2, für den Coova bestimmt ist. Ich habe diese Brücke so eingerichtet, dass sie auf eth2 zeigt, da von hier aus die Accespoints angesteuert werden. Wenn ich die Anleitungen richtig verstehe, bekommt von den beiden (?) Netzwerkkarten, die man dem virtuellen Coova gibt, die erste br2. Wie aber wird mit virt-manager die zweite konfiguriert? Ich muss da irgendwas angeben. Muss eine weiteres rein virtuelles Device einrichten, kann ich die als NAT einstellen? Oder liegt mein Denkfehler ganz wo anders. Brauche ich am Ende nur eine, nämlich br2? Ich bin einigermaßen verwirrt und für jeden Tipp dankbar. Wahrscheinlich sehe ich den Wald vor lauter Bäumen nicht mehr. Gruß vom verwirrten christian huber ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
[lmn] Kein Zugriff auf Online-Vertretungsplan
Hallo, danke für die Antworten. Wie immer waren die Tipps echt hilfreich. Irgendwie vermisse ich eine Mail, mit der ich gestern Abend noch auf Christophs Mail geantwortet habe. Ich gebe sie hier nochmal wieder: "Hallo Christoph, Zu 1. Jep, eine .htaccess existiert. Sie sieht so aus: AuthType Basic AuthName "Vertretungsplan Lehrer" AuthBasicProvider ldap AuthLDAPUrl ldaps://10.16.1.1/dc=paedml-linux,dc=lokal?uid AuthLDAPGroupAttributeIsDN off AuthLDAPGroupAttribute memberUid Require ldap-group cn=teachers,ou=groups,dc=paedml-linux,dc=lokal21:43/0 Zu 2. Nach dem Umbenennen funktioniert der Zugriff auf die Seite. Keine Anmeldung erforderlich. Zu 3. Benutzer und Gruppe sind jeweils root. Habe das in www-data geändert und komme noch immer anmeldefrei auf die Seite. Weiterhin habe ich nach dem Umbenennen die .htaccess wieder hergestellt. Der Fehler erscheint dann wieder. Immerhin kommt Bewegung in die Sache. " Das war der Stand gestern Abend. Ich habe mir heute Vormittag dann nochmal die Wiki-Seite zum Thema .htaccess durchgelesen und daraufhin folgendes gemacht: 1. Benutzer und Gruppe der Datei .htaccess wieder in www-data.www-data geändert 2. in /etc/apache2/sites-enabled/000-default den Eintrag LDAPVerifyServerCert OFF hinzugefügt, um die Abgleichung der Zertifikate zu verhindern. 3. /etc/init.d/apache2 reload Und damit war das Problem behoben. Vielen Dank für die Tipps. Lg christian hubber ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Listengrillen 2015
Moin zusammen, ich gehöre zu denen, die noch nichts vom Listengrillen wissen. Danke für die Einladung. Klingt nach ner super Sache. Ich bin dabei. Gruß Christian Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Holger Baumhof Datum: 10.02.2015 22:58 (GMT+01:00) An: Mailingliste Betreff: [lmn] Listengrillen 2015 Hallo alle zusammen, auch dieses Jahr gibt es wieder ein Listengrillen bei mir im Garten. Termin ist der 13.6.2015 Für die von euch, die das noch nicht kennen: einmal im Jahr lade ich in meinen Garten ein: da treffen wir uns Nachmittags und grillen gegen Abend. Und dann sitzen wir im Garten bis in die Nacht. Letztes Jahr waren wir nicht gar so viele: ca. 10: da ist also noch Platz. Adresse gibt es für jeden per PM. Ich wohne Nahe Karlsruhe. Eingeladen sind alle Listenteilnehmer, die gerne kommen wollen. Jeder bringt was zu grillen mit, und, wenn er mag, einen Salat oder was zu knabbern. Was zu trinken kann man auch mitbringen. Ich besorge Baguette und stelle die Saucen bereit. Wer mit dem Zug anreist kann bescheid sagen, dann hohl ich ihn(sie?) vom Bahnhof Karlsruhe ab. Wer Kinder mitbringen will, kann das auch machen: meine beiden Töchter (8 und 14) werden auch da sein. Wir hatten sogar schon Ehefrauen/Freundinnen mit dabei, und es heißt, denen habe es auch gefallen :-) Ich habe einen 25kg Hund (ist nicht dicker geworden) von dem man sich leider einmal beschnüffeln lassen muss: aber der beißt nur sein Trockenfutter :-) Falls noch jemand einen Hund mitbringen will: meiner ist nicht territorial und hat somit kein Problem damit "seinen" Garten mit anderen Hunden zu teilen. Wir wollen wieder ab 13 Uhr anfangen mit ausgiebigem Kaffee/Tee was dann fließend in grillen über geht. Im nächsten Dorf gibt es eine Pension, falls jemand weit gereist kommt .. Als Entschädigung für die Umstände ist man dann auch gleich zum Frühstück am Sonntag eingeladen. Die Pension ist 2km von mir Zuhause weg: man kann also Nachts auch laufen. Ich freu mich: erscheint recht Zahlreich, bisher hatten wir noch immer genügend Platz. Viele Grüße Holger ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
