[PUG] isdn debian stoerungsmeldung ...
Hallo Liste, so, jetzt habe ich das Ganze soweit aufgesetzt. Beim Einwählen aber gibt es folgende Meldung in /var/log/messages: Jul 28 12:49:53 debiankoek kernel: ippp0: dialing 1 10190192231750... Jul 28 12:50:00 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 12:50:02 debiankoek kernel: isdn_net: local hangup ippp0 Jul 28 12:50:02 debiankoek kernel: ippp0: Chargesum is 0 Danach gegoogelt habe ich natürlich auch schon. Dort spricht man von Kabelbrüchen und Ähnlichem. Das kann es nicht sein: auf der gleichen Kiste läuft ISDN unter Mandrake 9.1 - wie diese mail hier zeigt. Hat Jemand eine Idee ? Gruß, Michael Bischof PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] x-session auf anderen rechner uebernehmen
Hallo! Das nutzt Dir nur nichts, wenn Du tagsüber einen Server rebooten oder ein Filesystem offline nehmen willst, denn Du kannst Prozesse (vermutlich, korrigiert mich, wenn ich falsch liege) nicht von einem Knoten zum anderen verlagern, weder bei SunRay noch bei XDMCP. Da überkamen mich beim späteren Lesen doch Selbstzweifel und ich habe mal in der SunRay-Doku nachgelesen: (http://wwws.sun.com/hw/sunray/whitepapers/SunRay_WP042403.pdf) Sun Ray implementations require well-designed networks. Sun Ray Server Software allows servers to be configured in high-availability (HA) groups to ensure service whenever a server goes offline and to perform load balancing. Once a high-availability group is set up, Sun Ray Server Software provides automatic load balancing, optimizing performance by distributing sessions among the servers in the group. If a server fails, the Group Manager on each remaining server spreads the offline serverts sessions evenly among the remaining servers. Also werden die Login-Sessions doch on-the-fly von einem Server vom anderen verlagert. Bäh. Wenn man keine Ahnung hat, sollte man besser das Maul halten. ;-) Coole Sache, also ist das Eisen doch viel weniger heiß als befürchtet. Nein, Load Balancing bezieht sich auf neue Sessions. Wenn ein Server abschmiert, dann ist Stand heute Deine Session weg. Du kannst Dich dann auf einem der uebrig gebliebenen Server neu anmelden. Mit welchem SunRay Server Du verbunden wirst, das wird vom Load Balancing gesteuert (kann aber auch manuell beeinflusst werden). Ist aber von den Marketing-Kollegen clever formuliert. ;-) Das Mitnehmen von Sessions/Prozessen wuerde bedeuten, dass die Prozess-Informationen persistent gemacht werden (ueber Storage oder Netzwerkverbindungen wie bei Oracle RAC) - das willst Du aus Performancegruenden nicht. Gruss Dieter -- Dieter Heiliger | [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (business) PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] x-session auf anderen rechner uebernehmen
Hallo Dieter Heiliger, dear Dieter Heiliger, * [EMAIL PROTECTED] wrote/schrieb: Server Software allows servers to be configured in high-availability (HA) groups to ensure service whenever a server goes offline and to perform load balancing. Once a high-availability group is set up, Sun Ray Server Software provides automatic load balancing, optimizing performance by distributing sessions among the servers in the group. If a server fails, the Group Manager on each remaining server spreads the offline serverts sessions evenly among the remaining servers. Coole Sache, also ist das Eisen doch viel weniger heiß als befürchtet. Nein, Load Balancing bezieht sich auf neue Sessions. Wenn ein Server abschmiert, dann ist Stand heute Deine Session weg. Du kannst Dich dann auf einem der uebrig gebliebenen Server neu anmelden. Mit welchem SunRay Server Du verbunden wirst, das wird vom Load Balancing gesteuert (kann aber auch manuell beeinflusst werden). Ist aber von den Marketing-Kollegen clever formuliert. ;-) Die Marketing-Kollegen werden eh die ersten sein, die an die Wand gestellt werden, wenn die Revolution kommt. Ich lese ziemlich unmißverständlich: Wenn ein Server ausfällt verteilt der Group Manager die Sitzungen des ausgefallenen Servers auf die verbliebenen Server. Es ist also etwas vorhanden (gewissermaßen verwaiste Sitzungen vom ausgefallenen Server), und das wird irgendwo anders hingetan (auf eine der Backup-Maschinen). Wenn die anderen Server nichts von den Sitzungen des ausgefallenen Servers wissen können, können sie folglich auch keine Sitzungen des ausgefallenen Servers übernehmen. Das Mitnehmen von Sessions/Prozessen wuerde bedeuten, dass die Prozess-Informationen persistent gemacht werden (ueber Storage oder Netzwerkverbindungen wie bei Oracle RAC) - das willst Du aus Performancegruenden nicht. Ich hatte es ja zunächst auch ausgeschlossen, aber eure Doku legt nun einmal nahe, daß ihr dafür eine tolle Lösung habt. -martin -- Busier than a one-legged man in an ass-kicking contest. PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] isdn debian stoerungsmeldung ...
Hallo, Hallo Liste, so, jetzt habe ich das Ganze soweit aufgesetzt. Beim Einwählen aber gibt es folgende Meldung in /var/log/messages: Jul 28 12:49:53 debiankoek kernel: ippp0: dialing 1 10190192231750... Kann es sein, daß du einfach noch eine Null vorwählen mußt? Tschau MartinD: -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern! PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] x-session auf anderen rechner uebernehmen
Hallo Martin! Server Software allows servers to be configured in high-availability (HA) groups to ensure service whenever a server goes offline and to perform load balancing. Once a high-availability group is set up, Sun Ray Server Software provides automatic load balancing, optimizing performance by distributing sessions among the servers in the group. If a server fails, the Group Manager on each remaining server spreads the offline serverts sessions evenly among the remaining servers. Coole Sache, also ist das Eisen doch viel weniger heiß als befürchtet. Nein, Load Balancing bezieht sich auf neue Sessions. Wenn ein Server abschmiert, dann ist Stand heute Deine Session weg. Du kannst Dich dann auf einem der uebrig gebliebenen Server neu anmelden. Mit welchem SunRay Server Du verbunden wirst, das wird vom Load Balancing gesteuert (kann aber auch manuell beeinflusst werden). Ist aber von den Marketing-Kollegen clever formuliert. ;-) Die Marketing-Kollegen werden eh die ersten sein, die an die Wand gestellt werden, wenn die Revolution kommt. Hatte ich schon erwaehnt, dass Marketing meine Vertiefung im BWL-Teil des Wirtschaftsinformatik-Studiums war? Aber ich habe mich ja bereits durch den Standdienst disqualifiziert und setze mich wohl besser frueher als spaeter ab ... ;-))) Ich lese ziemlich unmißverständlich: Wenn ein Server ausfällt verteilt der Group Manager die Sitzungen des ausgefallenen Servers auf die verbliebenen Server. Es ist also etwas vorhanden (gewissermaßen verwaiste Sitzungen vom ausgefallenen Server), und das wird irgendwo anders hingetan (auf eine der Backup-Maschinen). Wenn die anderen Server nichts von den Sitzungen des ausgefallenen Servers wissen können, können sie folglich auch keine Sitzungen des ausgefallenen Servers übernehmen. Ich stimme Dir zu, dass das ungluecklich formuliert ist und befuerchte, dass der Autor des Papers sich auf den Inhalt des Begriffs Session zurueckzieht. Die Session wird in der Tat verteilt - sie ist anschliessend halt dummerweise leer. :-( Wie gesagt, ich haette das so nicht geschrieben. Ich erzaehle jedem, der es wissen will, dass Stand heute die Session weg ist und man sich neu anmelden muss. Aber deshalb bin ich ja auch Systemberater und nicht im Marketing (und mochte eh den Informatik-Teil meines Studiums viel lieber!). Bei uns hier in der Geschaeftsstelle gibt es die bereits auf dem Linuxtag erwaehnten ca. 300 Arbeitsplaetze und die sind mit 3 Servern verbunden. Diese Server sind natuerlich heiss (um hier mal Deine Begriffe zu zitieren). Aber wenn man Server konsolidieren und damit Kosten reduzieren moechte, dann muss man das in Kauf nehmen und die Kisten entsprechend behandeln. Meine Session hier im Buero ist nicht haeufiger als einmal pro Jahr ungeplant weggefallen - und ich melde mich nur am Wochenende ab. Ich will hier auch gar nicht zu sehr Werbung fuer die SunRays machen (obwohl ich persoenlich die Technik toll finde). Vielmehr geht es mir um einen Trend in der IT: Wenn ich Server konsolidiere, dann fasse ich automatisch auch Benutzer zusammen und dann muss ich die Server anders behandeln als in dem Fall, bei dem jeder Nutzer seine eigene Hardware zugeordnet hat. Letzteres ist bequem - aber evtl. teurer. Gruss Dieter -- Dieter Heiliger | [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (business) PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] x-session auf anderen rechner uebernehmen
On Sun, Jul 27, 2003 at 09:24:24PM +0200, Martin Schmitt wrote: Das nutzt Dir nur nichts, wenn Du tagsüber einen Server rebooten oder ein Filesystem offline nehmen willst, denn Du kannst Prozesse (vermutlich, korrigiert mich, wenn ich falsch liege) nicht von einem Knoten zum anderen verlagern, weder bei SunRay noch bei XDMCP. Selbst wenn Du es abends oder Mag sein das sun das noch nicht kann, für Linux gibts dafür bei Sourceforge ein Projekt. -- May the source be with you! PUG - Penguin User Group Wiesbaden - http://www.pug.org
[PUG] isdn debian III hisax...
Hallo Liste, so, inzwischen habe ich mit modconf die Treiber eingebunden. Meine isdn-Karte ist eine AVM A1 ISDN FritzCard avm PCI, c000-c01f. Dafür sollte man nach der Literatur nur den hisax-Treiber laden müssen. Dann aber geht das Kommando /etc/init.d/isdnutils start nicht. Binde ich auch noch hisax- fcpcipnp-Treiber ein kriege ich folgenden Fehler: debiankoek:/home/michael# tail -f /var/log/messages Jul 28 21:27:22 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:27:24 debiankoek kernel: ippp0: dialing 6 101901929... Jul 28 21:27:31 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:27:33 debiankoek kernel: ippp0: dialing 7 101901929... Jul 28 21:27:40 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:27:41 debiankoek kernel: ippp0: dialing 8 101901929... Jul 28 21:27:48 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:27:50 debiankoek kernel: ippp0: dialing 9 101901929... Jul 28 21:27:57 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:27:58 debiankoek kernel: ippp0: dialing 10 101901929... Jul 28 21:28:05 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Jul 28 21:28:06 debiankoek kernel: NETDEV WATCHDOG: ippp0: transmit timed out Jul 28 21:28:06 debiankoek kernel: isdn_tx_timeout dev ippp0 dialstate 4 Jul 28 21:28:07 debiankoek kernel: isdn_net: local hangup ippp0 Das Teil wählt, nach isdnctrl status ippp0 ist es auch verbunden, aber es kommt immer sogleich zu einem local hangup. Wohlgemerkt: die gleiche Karte funktioniert auf der gleichen Kiste mit Mandrake 9.1 einwandfrei. Ist Debian zu hoch für mich ? Googeln brachte mich nicht weiter ... Gruß, Michael Bischof PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] isdn debian III hisax...
Hallo! * Michael Bischof wrote/schrieb: debiankoek:/home/michael# tail -f /var/log/messages Jul 28 21:27:22 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Cause #27 1B Die gerufene Teilnehmerschnittstelle ist zur Zeit außer Betrieb. Jul 28 21:27:24 debiankoek kernel: ippp0: dialing 6 101901929... Die Nummer ist falsch, da fehlt ne 0. Gruß //Robert -- Robert Weißgraeber-o) [EMAIL PROTECTED] /\\ _\_V Message void if penguin violated ... Don't mess with the penguin PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] isdn debian III hisax...
Am Montag, 28. Juli 2003 21:35 schrieb Robert Weißgraeber: Hallo! * Michael Bischof wrote/schrieb: debiankoek:/home/michael# tail -f /var/log/messages Jul 28 21:27:22 debiankoek kernel: isdn: fcpcipnp0,ch0 cause: E001B Cause #27 1B Die gerufene Teilnehmerschnittstelle ist zur Zeit außer Betrieb. Jul 28 21:27:24 debiankoek kernel: ippp0: dialing 6 101901929... Die Nummer ist falsch, da fehlt ne 0. Ja, klar: die Installationsanleitung betont daß man die 0 extra nicht miteingeben soll ! also: 67346713 für meine eigene Telefonnummer statt 06734... 1011901929 statt 0101901929 Wundert mich auch, ... Danke für den Hinweis ! Michael Bischof PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] cron Problem mit fetchnews
On Mon, 28 Jul 2003 at 22:51 (+0200), Christian Schmidt wrote: Hallo, leider wird mein cronjob zum Abholen der News funktioniert nicht. Es gibt auch keinerlei log-Einträge. Zumindest finde ich Sie nicht in syslog. Ich habe die aktuelle leafnode-Version kompiliert und installiert, alles nach Anleitung. mit crontab -u news -a SHELL=/bin/sh 0 4 * * * /usr/local/sbin/texpire */5 * * * /usr/local/sbin/fetchnews Ein händischer Aufruf von leafnode als user news funktioniert auch, an den Rechten liegt es also nicht. Was fehlt mir denn noch? Mit einem Eintrag in /etc/crontab funktioniert es. Wo ist jetzt das Problem mit dem user-crontab? chris PUG - Penguin User Group Wiesbaden - http://www.pug.org
