Vieleicht solltem man noch erwähen, dass eine Menge Informationen direkt aus dem IP-UP/IP-DOWN Script direkt gibt weil sie von pppd/ipppd gesetzt werden.
So kann man schon ein Primitivlogging machen indem man foldende Zeile ins ip-down script schreibt:
folgende Umgebungsvariablen gibts: (ziemlich am Ende von man pppd )
DEVICE : Device der Verbindung IFNAME : Name des akt. Devices IPLOCAL : Lokale IP IP Remote :Remote IP PEERNAME : Name des Providerserver (Nur wenn er sich authentifiziert hat)
ORIG_UID : Userid des Benutzers, der pppd gestartet hat
PPPLOGNAME : Name des Benutzers
Nu wirds Interessanter (nur in ip-down):
CONNECT_TIME: Verbindungsdauer in Sekunden BYTES_SENT , BYTES_RCVD, LINKNAME
Interessant. Entweder sind diese Umgebungsvariablen in meiner ipppd-Manpage nicht dokumentiert, oder ich habe sie übersehen. Damit könnte man das Tabellenformat etwas vereinfachen.
ich hab die Angaben aus der Manpage von pppd ver. 2.4.0
Ich weiss nicht wie "neu" diese Mimik ist. Ich bin selber erst vor kurzem drueber gefallen, als ich mit dem demand-dialing Mode von pppd experimentiert habe, um mir diald zu sparen.
Deine Aussage, dass ip-up und ip-down die selbe Datei ist, stimmt nicht immer. Bei manchen Distributionen ist das der Fall, aber eigentlich kann man auch zwei verschiedene Dateien haben.
Viel zu umständlich! Ich fahr extra dafür ne SQL Datenbank mithoch damit ich die Onlinezeit ablesen kann. Da gibts bestimmt noch ne einfachere Lösung und wenn es ein TCL/Tk, Java, Perl Script ist.
für user, die keine datenbank am laufen habe, ist das wohl ein bisschen over-killed, dafür extra die postgres anzuwerfen.
eine simplere lösung ohne datenbank wäre wohl sicher günstiger.für mich läuft das so unter die kategorie, wo gezeigt wird, was man mit ner db sonst noch alles machen kann (sorry, nicht böse gemeint).
Ne Datenbank auf einem Einwahlrechner ist wohl eher eine schlechte Idee.
Ich mache das zwar auch über ip-up und ip-down, aber die schreiben einfach die Zeiten in eine Datei. Diese kann man dann mit Perl nach Lust und Laune auswerten.
Es ist kein Einwahl- sondern ein Auswahlrechner Paketfilter blocken nahezu alle eingehenden Pakete.
Außerdem könnte der DB-Server auch auf einem anderen Rechner laufen. PostgreSQL ist netzwerkfähig. Im Moment ist es bei mir halt so, daß der Server auch die ISDN-Karte hat.
Mich interessiert das schon. Dann kann ich sagen das ich Internetsüchtig bin und es beweisen *lol* wenn wieder mal so ein artikel durch die Medien geht. *freu*
Nette Idee, aber ich denke, mir wird kppp ewig reichen. Hab was gegen auto-dial. Aber wer KDE nicht mag... ;-) der darf mit Kanonen auf Spatzen schiessen
Ok, dass DSL herrlich ist, duerfte jedem klar sein, aber wer sich eine Telefonrechnung von ueber 100,- DM nur mit Grundgebühren nicht leisten kann, der muss halt ein anderes Modell waehlen..
coole idee, weiter so, bin gespannt, wie's weitergeht!
BTW: ip-up wird vom pppd ausgefuehrt, wenn ppp0 oben ist und ip-down, wenn ppp0 wieder down ist. diese scripte sind nicht in stein gemeisselt sie koennen frei editiert und den eigenen wuenschen und vorstellungen angepasst werden, zb das anlegen einer semaphore fuer den onlinestatus in /tmp
Klar. Aber ich wollte keine Datei verwenden. Zumal die Verwendung von /tmp ein Sicherheitsproblem sein kann.
Wie es weitergeht? Mir ist eingefallen, daß man mit der Zeit auch gleich den angefallenen Traffic speichern könnte. Dazu muß man nur /proc/net/dev auswerten. Demnächst...
Dann könnte man die Auswertung noch automatisieren. Ein Skript, das etwas Ähnliches macht, habe ich schon vor Jahren mal geschrieben. Aber vielleicht ist es auch einfacher, erst mal isdnrep wieder zum Laufen zu bringen
Von Bernd Mueller am Mo, 20. August 2001 um 17:22 #
Hallo
@hjb: hast du irgendwelche dokus zu /proc/net/dev? angeregt durch deine idee hab ich grade eben ein php script zusammngeschustert das /proc/net/dev ausliest und auf eine webseite ausspuckt. allerdings sieht das ziemlich besch....eiden aus irgendwie müssen die tausend leerzeichen ( tab's? ) noch raus damit es lesbar wird. bye / Bernd /
Ich benutze dafür LineControl (http://homepage.swissonline.ch/allenfuchs/stefan/lc/) das ist ein Einwahlserver (mit entsprechenden Clients für sämtliche BSe). Sowas hat natürlich im Netzwerk einige Vorteile, aber für den Einzelplatzrechner ist der Aufwand auch nicht sehr groß und natürlich, deshalb schreibe dieses, hat LineControl ein cgi-Skript mit den man die Einwahlzeit (sogar nach Benutzer) auslesen kann.
Von Daniel Kratzert am So, 19. August 2001 um 17:50 #
Ich beutze den Vorläufer von LineControl (DialControl), der ist einfscher zu konfigurieren und kann auch schon das, was ich brauche. Die Onlinezeit für jeden benutzer werte ich mit einem shellscript aus.
Von kaptain-blaubaer am So, 19. August 2001 um 17:43 #
Nur zur Info:
Für so etwas nimmt man "ip-up.local" bzw "ip-down.local".
Ausserdem: Wo ist das Problem mit den logfiles, die der pppd über syslogd schreibt? Wenn du nicht willst, daß sie archiviert werden, dann schalte einfach logrotate dafür aus!
Stattdessen wird einfach um das Problem herumprogrammiert: Völlig unverständlich!
ganz ruhig Gibt eben immer mehrere Lösungen... auch wenns nich die beste ist... mit ip-up.local und so weiter hast du aber recht... dafür sind die ja da. :)
also "ip-up.local" bzw "ip-down.local" ist ja schön und gut. Aber was mache ich, wenn ich adsl habe ??, da wäre eine Kontrolle auch ganz gut. In Windoof gibt es so was für isdn und adsl. Das sind so die Kleinigkeiten, die ich in Linux vermisse.
Ich habe keine Ahnung vom Programmieren. Möchte ich auch nicht. Bin nur normaler Linuxuser (Homeuser), der von Windoof auf Linux umgestiegen ist. Für solche Kleinig- keiten muß es doch schon fertige kleine Programme geben. Das erwarte ich eigentlich von Linux. Ich habe das Problem so gelößt, das ich eine Stopuhr mitlaufen lasse, wie gtimetracker. Das Programm wird auto- matisch gestartet mit netscape.
Von kaptain-blaubaer am So, 19. August 2001 um 20:46 #
>> Für so etwas nimmt man
> Das mag für Distributionenzutreffen, > die diese Dateien anbieten, ich habe > und brauche sie aber nicht. Natürlich sind diese Dateien nicht vorhanden. Du sollst sie ja erstellen. Denn deine "ip-up" landet nach einen Upgrade, je nach Distribution, in "ip-up.rpmsave" Also ich habe in den letzten Jahren keine Distribution gefunden, die in "ip-up" keinen Test auf "ip-up.local" durchführt. Was hast du denn für eine Distribution?
> Ich will aber, daß sie archiviert > werden. Ich ändere doch nicht mein > über 7 Jahre gepflegtes Setup, um > ein kleines Problemchen zu lösen.
Dann durchsuch doch die Archive, ist doch auch kein Problem....
Ähm, RPM? Auf einer Slackware von 1994? Ich spiele *nie* Binärpakete auf meinem Server ein. Daher brauche ich auch keinen Aufruf von ip-up.local, ich kann ip-up direkt modifizieren. Nix gegen deinen Hinweis, ich wußte aber nicht mal, daß manche Distros sowas wie ip-up.local haben.
> Dann durchsuch doch die Archive, > ist doch auch kein Problem....
Doch. Wie ich im Tip geschrieben habe, würde die Suche (und der Einbau ins System) länger dauern, als etwas Eigenes zu entwickeln. Und muß ich noch erwähnen, was interessanter ist?
tja aber wenn mann die verbindungen der vergangene Zeit ausrechnen möchte kommt diese Idee zu spät. ich habe einfach mit kommandozeilen tools das ganze gelöst. es wird ja in /var/log/massages eh alles gelogt man kann die Datei einfach nach pppd durch suchen und in eine datei umleiten zB cat massages|grep pppd >pppd.log und da habe ich dann auch gleich untersucht wie mein ISP mir die IP verteilung regelt (das hat mich schon immer interresiert...) wenn man jetzt die online zeit berechnen will muss man pppd start zeit und stop zeit suchen lassen und und und ich gebe zu es ist umständliche, aber es ist nicht nöti einen Datenbank laufen zu lassen und wie gesagt es ist im nachhinein auch noch eisetzbar!!!
ok die lösung habe ich dann nicht zu ende gebracht da ich dsl bekamm und dan .... :)) aber vieleich arbeite ich das teil noch aus und stelle es unter GPL frei
Das habe ich mir auch überlegt. Mit etwas Perl wäre es recht simpel gewesen, bis auf die Tatsache, daß meine Logs nur zwei Wochen zurückreichen und, wie gesagt, jeden Tag eine neue Datei angelegt wird. Das hätte es im Endeffekt doch recht kompliziert gemacht. Ich wollte es einfacher...
Also, ich habe mir sowas schon mal vor laengerer Zeit mit Perl selbst gebastelt: Ein Script fuer ip-up und ein weiteres fuer ip-down, sind zusammen gerade mal 20 Zeilen und die Online-Zeit wird auch direkt mit ausgerechnet :-) Fliesst allerdings noch in 'ne Datei, Datenbank-Anbindung waer aber auch kein Problem.
Moin HJB, wärs nicht besser die Start- und Endzeit-Felder als Typ timestamp zu deklarieren? Das würde das Errechnen der Verbindungszeit vereinfachen, speziell wenn man um die 0:00h online war.
Von Torsten Schneider am Mi, 22. August 2001 um 15:26 #
Die Lösung ist ja gut, aber zwei ANmerkungen hätte ich noch:
Zum einen bekommt man Probleme, wenn pppd unsauber terminiert wird und die Endezeit deswegen nicht eingetragen wird. die Update-Anweisung stellt alle noch offenen Verbindungen auf den selben Endepunkt, deswegen sollte man noch ein delete from online where endtime = null machen.
Desweiteren halte ich time für einen denkbar schlechten Datentyp, da dort nur die Uhrzeit, aber nicht das Datum enthalten ist. Wenn man sich vor Mitternacht einloggt und nach Mitternacht wieder ausloggt, hat man ein Problem. timestamp wäre der bessere Datentyp.
Halt, ich nehme alles zurück timestamp ist der richtige Datentyp. Das ist auch das, was ich verwende. Im Tip habe ich versehentlich die Typen verwechselt.
ich hab mich gefragt ob eigentlich auf keinem eurer Systeme isdnlog läuft. Der erzeugt nämlich die Datei /var/log/isdn.log und da steht in einem Feld drin wie lange du jeweils online warst und zwar in Sekunden ohne dass du noch ne Differenzausrechnen musst. "man 5 isdnlog" bringt näheres zu dieser Datei. Da kann man dann mit einem kleinen Perl Skript die Zeiten zusammenaddieren und schon weiß man wie lange ich exakt online war. Das mit ip-up ist nicht sonderlich genau, da die erst ausgeführt wird wenn ich schon online _bin_. Da können also Differenzen entstehen dass am Monatsende zu wenig Onlinezeit angezeigt wird, was bei der isdn.log Variante wohl auszuschließen sein dürfte. Außerdem ist ne DB ja schon nett, aber wieso ne DB wenn alles schon (und vor allem so zuverlässig und schön) in einer Datei steht?
isdnlog ist leider gar nicht so zuverlässig und hängt sich regelmäßig nach einiger Zeit auf und logt einfach nicht mehr. Das ist natürlich umso besch... da man es immer zu spät merkt. Ist das inzwischen gefixt worden?
An isdn.log habe ich irgendwie gar nicht gedacht. Ja, isdnlog läuft zuverlässig und hat bei mir noch nie irgendwelche Probleme gemacht. Leider ist isdnrep zum Auswerten des Logs nicht gerade der Brüller. Scheint eine Menge Bugs zu haben, so kann ich z.B. keine Zusammenfassung von einer Woche oder einem Monat bekommen.
Aber isdnlog hat auch die Möglichkeit, die gleichen Daten in eine PostgreSQL- oder MySQL-Datenbank zu schreiben. Leider muß man das beim Compilieren aktivieren, was ich jetzt mal gemacht habe.
Das mit der Datenbank wusste ich nicht, aber du brauchst ja nicht isdnrep zum Auswerten nehmen sondern kannst da dein eigenes Perl Skript schreiben, das du ja auch für deine Lösung brauchen würdest, aber das ist wesentlich einfacher, weil du die Daten schon sehr viel genauer und ausführlicher hast als mit der ip-wurschtel-up Lösung. Das Problem mit den Wochenzusammenfassungen kannst du ja relativ simpel selber lösen wofür gibt es denn Perl Module und Reguläre Ausdrücke. Ich werd mir jetzt mal ein Skript für meine Surftime 90 von t-online schreiben, die immer am 8. des Monats abgerechnet wird, was aber noch eine Weile dauern kann, da ich gerade noch was anderes machen muss, aber dann kann ich es dir mal schicken.
da hätte ich Interesse dran. Inzwischen schreibt isdnlog die Daten auch brav in die Tabelle, und da die Tabelle Datum und Zeit trennt, sollte es kein Problem sein, eine Query mit "group by sdate" oder so zu machen, die das ziemlich einfach auswertet.
Meine ursprüngliche Idee ist damit nur noch für nicht-ISDN-Nutzer interessant. Es würde sich anbieten, statt meiner schnell mal entworfenen Tabelle die gleiche Tabelle wie isdnlog zu verwenden. So könnte eine Abfrage für alle User reichen.
Da sind jetzt aber so viele Ideen zusammengekommen, daß man direkt einen Artikel daraus machen sollte. Ich versuche, das in den nächsten Wochen irgendwie reinzuschieben. Oder möchte jemand anders den Artikel verfassen?
Danke an alle, die zu der Diskussion beigetragen haben.
Habe auch schon länger nach solch einer Lösung gesucht. Echt ne prima idee. Werde ich auch mal umsetzen :-)
Danke für den Tipp.
Greetz ... Stephan !
So kann man schon ein Primitivlogging machen indem man foldende Zeile ins ip-down script schreibt:
echo ${PPPLOGNAME} ${IFNAME} ${IPLOCAL} ${CONNECT_TIME} ${BYTES_SENT} ${BYTES_RCVD}
/var/log/pppd.log
folgende Umgebungsvariablen gibts:
)
(ziemlich am Ende von man pppd
DEVICE : Device der Verbindung
IFNAME : Name des akt. Devices
IPLOCAL : Lokale IP
IP Remote :Remote IP
PEERNAME : Name des Providerserver
(Nur wenn er sich authentifiziert hat)
ORIG_UID : Userid des Benutzers, der pppd gestartet hat
PPPLOGNAME : Name des Benutzers
Nu wirds Interessanter (nur in ip-down):
CONNECT_TIME: Verbindungsdauer in Sekunden
BYTES_SENT , BYTES_RCVD, LINKNAME
Gruß Dolmant
ich hab die Angaben aus der Manpage von pppd ver. 2.4.0
Ich weiss nicht wie "neu" diese Mimik ist. Ich bin selber erst vor kurzem drueber gefallen, als ich mit dem demand-dialing Mode von pppd experimentiert habe, um mir diald zu sparen.
Gruß Dolmant
Noch etwas. Du verweist zweimal auf die Datei "ip-down". Ist das korrekt so ? Müsste es nicht einmal die Datei "ip-up" sein ?
Greetz ... Stephan !
Deine Aussage, dass ip-up und ip-down die selbe Datei ist, stimmt nicht immer. Bei manchen Distributionen ist das der Fall, aber eigentlich kann man auch zwei verschiedene Dateien haben.
für user, die keine datenbank am laufen habe, ist das wohl ein bisschen over-killed, dafür extra die postgres anzuwerfen.
eine simplere lösung ohne datenbank wäre wohl sicher günstiger.für mich läuft das so unter die kategorie, wo gezeigt wird, was man mit ner db sonst noch alles machen kann (sorry, nicht böse gemeint).
grüsse,
daniel
> (i)pppd ipparam $PROVIDER
(Siehe man pppd)
Bei mir steht dieser Aufruf z.B. in /etc/rc.d/init.d/isdn.
Ich mache das zwar auch über ip-up und ip-down, aber die schreiben einfach die Zeiten in eine Datei. Diese kann man dann mit Perl nach Lust und Laune auswerten.
cu, andreaz
Außerdem könnte der DB-Server auch auf einem anderen Rechner laufen. PostgreSQL ist netzwerkfähig. Im Moment ist es bei mir halt so, daß der Server auch die ISDN-Karte hat.
Was ineteressiert die online Zeit, wenn man eine Kabelinternet "Standleitung" hat ;-)
Meinolf
gruss Ghoja
Hab was gegen auto-dial.
Aber wer KDE nicht mag... ;-)
der darf mit Kanonen auf Spatzen schiessen
für alle Dial-in User die nicht jedesmal wenn die Telefonrechnung kommt weiche Knie bekommen wollen, können solche Tips schon sinnvoll sein.
ueber 100,- DM nur mit Grundgebühren nicht leisten kann, der muss halt ein anderes Modell waehlen..
coole idee, weiter so, bin gespannt, wie's weitergeht!
BTW: ip-up wird vom pppd ausgefuehrt, wenn ppp0 oben ist und ip-down, wenn ppp0 wieder down ist. diese scripte sind nicht in stein gemeisselt
sie koennen frei editiert und den eigenen wuenschen und vorstellungen angepasst werden, zb das anlegen einer semaphore fuer den onlinestatus in /tmp
ratte
Wie es weitergeht? Mir ist eingefallen, daß man mit der Zeit auch gleich den angefallenen Traffic speichern könnte. Dazu muß man nur /proc/net/dev auswerten. Demnächst...
Dann könnte man die Auswertung noch automatisieren. Ein Skript, das etwas Ähnliches macht, habe ich schon vor Jahren mal geschrieben. Aber vielleicht ist es auch einfacher, erst mal isdnrep wieder zum Laufen zu bringen
@hjb: hast du irgendwelche dokus zu /proc/net/dev? angeregt durch deine idee hab ich grade eben ein php script zusammngeschustert das /proc/net/dev ausliest und auf eine webseite ausspuckt. allerdings sieht das ziemlich besch....eiden aus
irgendwie müssen die tausend leerzeichen ( tab's? ) noch raus damit es lesbar wird.
bye
/ Bernd /
http://www.forwiss.uni-passau.de/~berberic/Linux/ppplog.html
Für so etwas nimmt man
"ip-up.local" bzw "ip-down.local".
Ausserdem: Wo ist das Problem mit
den logfiles, die der pppd über syslogd schreibt? Wenn du nicht willst, daß sie archiviert werden,
dann schalte einfach logrotate dafür aus!
Stattdessen wird einfach um das Problem herumprogrammiert: Völlig unverständlich!
kaptain-blaubaer
Trotzdem... Happy Scripting :)
Heckpart
"ip-up.local" bzw "ip-down.local" ist
ja schön und gut. Aber was mache ich, wenn
ich adsl habe ??, da wäre eine Kontrolle
auch ganz gut.
In Windoof gibt es so was für isdn und
adsl. Das sind so die Kleinigkeiten, die
ich in Linux vermisse.
> "ip-up.local" bzw "ip-down.local".
Das mag für Distributionen zutreffen, die diese Dateien anbieten, ich habe und brauche sie aber nicht.
> Wenn du nicht willst, daß sie
> archiviert werden, dann schalte
> einfach logrotate dafür aus!
Ich will aber, daß sie archiviert werden. Ich ändere doch nicht mein über 7 Jahre gepflegtes Setup, um ein kleines Problemchen zu lösen.
also
> "ip-up.local" bzw "ip-down.local" ist
> ja schön und gut. Aber was mache ich, wenn
>ich adsl habe ??
Diese Scripte werden auch aufgerufen, wenn die Einwahl per dsl erfolgt. Kein Unterschied.
Möchte ich auch nicht. Bin nur normaler
Linuxuser (Homeuser), der von Windoof auf Linux umgestiegen ist. Für solche Kleinig-
keiten muß es doch schon fertige kleine
Programme geben. Das erwarte ich eigentlich
von Linux. Ich habe das Problem so gelößt,
das ich eine Stopuhr mitlaufen lasse,
wie gtimetracker. Das Programm wird auto-
matisch gestartet mit netscape.
> Das mag für Distributionenzutreffen, > die diese Dateien anbieten, ich habe > und brauche sie aber nicht.
Natürlich sind diese Dateien nicht
vorhanden. Du sollst sie ja erstellen.
Denn deine "ip-up" landet nach einen
Upgrade, je nach Distribution, in "ip-up.rpmsave"
Also ich habe in den letzten Jahren
keine Distribution gefunden, die in
"ip-up" keinen Test auf "ip-up.local"
durchführt. Was hast du denn für eine
Distribution?
> Ich will aber, daß sie archiviert > werden. Ich ändere doch nicht mein > über 7 Jahre gepflegtes Setup, um
> ein kleines Problemchen zu lösen.
Dann durchsuch doch die Archive, ist doch auch kein Problem....
kaptain-blaubaer
> Dann durchsuch doch die Archive,
> ist doch auch kein Problem....
Doch. Wie ich im Tip geschrieben habe, würde die Suche (und der Einbau ins System) länger dauern, als etwas Eigenes zu entwickeln. Und muß ich noch erwähnen, was interessanter ist?
ich gebe zu es ist umständliche, aber es ist nicht nöti einen Datenbank laufen zu lassen und wie gesagt es ist im nachhinein auch noch eisetzbar!!!
ok die lösung habe ich dann nicht zu ende gebracht da ich dsl bekamm und dan .... :))
aber vieleich arbeite ich das teil noch aus und stelle es unter GPL frei
bye
Könnt ihr diese Smilie Icons nicht löschen? Ich kann Smilies inzwischen kaum mehr ausstehen, sie sind so penetrant. Diese gespielte Fröhlichkeit, bäh.
Und wenn sie auch noch als riesengrosser Icon auftreten, dann vermisst es den ganzen Text.
Nutze Mozilla und dein Problem ist gelöst
Nutzt immer den IE und die Probleme sind gelöst...
Meinst du hier auf pro-linux???
Welche Seiten werden hier nur mit IE korrekt angezeigt??
Würde mich echt wundern...
Fliesst allerdings noch in 'ne Datei, Datenbank-Anbindung waer aber auch kein Problem.
Wenn jemand Interesse dran hat, bitte melden.
wärs nicht besser die Start- und Endzeit-Felder als Typ timestamp zu deklarieren? Das würde das Errechnen der Verbindungszeit vereinfachen, speziell wenn man um die 0:00h online war.
Stiwi
hjb, wenn du dir die arbeit machst, waerst du so freundlich, mysql als datenbank mit zu beruecksichtigen?
das ware echt toll.
ratte
Zum einen bekommt man Probleme, wenn pppd unsauber terminiert wird und die Endezeit deswegen nicht eingetragen wird. die Update-Anweisung stellt alle noch offenen Verbindungen auf den selben Endepunkt, deswegen sollte man noch ein delete from online where endtime = null machen.
Desweiteren halte ich time für einen denkbar schlechten Datentyp, da dort nur die Uhrzeit, aber nicht das Datum enthalten ist. Wenn man sich vor Mitternacht einloggt und nach Mitternacht wieder ausloggt, hat man ein Problem. timestamp wäre der bessere Datentyp.
Torsten
Mit der time liegst du daneben. Die enthält auch das Datum.
ich hab mich gefragt ob eigentlich auf keinem eurer Systeme isdnlog läuft. Der erzeugt nämlich die Datei /var/log/isdn.log und da steht in einem Feld drin wie lange du jeweils online warst und zwar in Sekunden ohne dass du noch ne Differenzausrechnen musst. "man 5 isdnlog" bringt näheres zu dieser Datei. Da kann man dann mit einem kleinen Perl Skript die Zeiten zusammenaddieren und schon weiß man wie lange ich exakt online war. Das mit ip-up ist nicht sonderlich genau, da die erst ausgeführt wird wenn ich schon online _bin_. Da können also Differenzen entstehen dass am Monatsende zu wenig Onlinezeit angezeigt wird, was bei der isdn.log Variante wohl auszuschließen sein dürfte. Außerdem ist ne DB ja schon nett, aber wieso ne DB wenn alles schon (und vor allem so zuverlässig und schön) in einer Datei steht?
Viel Spaß noch,
Gruß Klaus
Das ist natürlich umso besch... da man es immer zu spät merkt.
Ist das inzwischen gefixt worden?
Aber isdnlog hat auch die Möglichkeit, die gleichen Daten in eine PostgreSQL- oder MySQL-Datenbank zu schreiben. Leider muß man das beim Compilieren aktivieren, was ich jetzt mal gemacht habe.
Das mit der Datenbank wusste ich nicht, aber du brauchst ja nicht isdnrep zum Auswerten nehmen sondern kannst da dein eigenes Perl Skript schreiben, das du ja auch für deine Lösung brauchen würdest, aber das ist wesentlich einfacher, weil du die Daten schon sehr viel genauer und ausführlicher hast als mit der ip-wurschtel-up Lösung. Das Problem mit den Wochenzusammenfassungen kannst du ja relativ simpel selber lösen wofür gibt es denn Perl Module und Reguläre Ausdrücke. Ich werd mir jetzt mal ein Skript für meine Surftime 90 von t-online schreiben, die immer am 8. des Monats abgerechnet wird, was aber noch eine Weile dauern kann, da ich gerade noch was anderes machen muss, aber dann kann ich es dir mal schicken.
Gruß Klaus
da hätte ich Interesse dran. Inzwischen schreibt isdnlog die Daten auch brav in die Tabelle, und da die Tabelle Datum und Zeit trennt, sollte es kein Problem sein, eine Query mit "group by sdate" oder so zu machen, die das ziemlich einfach auswertet.
Meine ursprüngliche Idee ist damit nur noch für nicht-ISDN-Nutzer interessant. Es würde sich anbieten, statt meiner schnell mal entworfenen Tabelle die gleiche Tabelle wie isdnlog zu verwenden. So könnte eine Abfrage für alle User reichen.
Da sind jetzt aber so viele Ideen zusammengekommen, daß man direkt einen Artikel daraus machen sollte. Ich versuche, das in den nächsten Wochen irgendwie reinzuschieben. Oder möchte jemand anders den Artikel verfassen?
Danke an alle, die zu der Diskussion beigetragen haben.