Hallo auch, Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
On Tuesday 02 September 2003 11:37, Bernd Tannenbaum wrote:
[...]
Wie man sieht, verwende ich eine simple Textdatei, in der ich einen Zählerstand speichere, der von jedem Terminal, das ich aufmache benutzt werden kann. Meine ursprünglichen Versuche konzentrierten sich allerdings eigentlich auf die Verwendung von "export". Ich hatte dran gedacht, eine globale Variable mit "20000" zu definieren und bei jedem Scriptaufruf hochzählen zu lassen. Nur wurde mein export-Befehl aus dem Shell-Programm nicht so wirklich umgesetzt. Ist das generell überhaupt möglich? Können verschiedene Terminals auf diese Art eine globale Variable gemeinsam nutzen und hochzählen oder bin ich da auf dem falschen Dampfer?
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
b) so etwas wie globale Variablen (in Deinem Sinne) gibt es nicht.
Mist. Ok, dann lass ich es mal so wie es ist. Funktioniert ja auch. Thx anyways, Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie. ------------------------------------------------------- -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
b) so etwas wie globale Variablen (in Deinem Sinne) gibt es nicht.
Mist. Ok, dann lass ich es mal so wie es ist. Funktioniert ja auch. Thx anyways,
/etc ist der vollkommen flasche Ort. Ich denke, /var/tmp ist am geeignetesten. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hullos, Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
Hmm, bist du da sicher? Das System einer Tokenvergabe sollte sich doch auch unter Linux realisieren lassen. Jan hat mir eine mögliche Lösung über Locks gemailt aber auch geschrieben, das dies nicht völlig sicher ist. Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende: 1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben. Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin? Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum wrote:
Hullos,
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
Hmm, bist du da sicher? Das System einer Tokenvergabe sollte sich doch auch unter Linux realisieren lassen. Jan hat mir eine mögliche Lösung über Locks gemailt aber auch geschrieben, das dies nicht völlig sicher ist. Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
Sieht eigentlich gut aus, was Du dir überlegt hast, ist aber ziemlich kompliziert für den von dir vorgesehenen Zweck. Vielleicht könnte für Dir /usr/bin/lockfile dienlich sein. Schau mal die manpage an. Gruss Werner
Am Mittwoch, 3. September 2003 09:15 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Hullos,
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
Hmm, bist du da sicher? Das System einer Tokenvergabe sollte sich doch auch unter Linux realisieren lassen. Jan hat mir eine mögliche Lösung über Locks gemailt aber auch geschrieben, das dies nicht völlig sicher ist. Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
Sieht eigentlich gut aus, was Du dir überlegt hast, ist aber ziemlich kompliziert für den von dir vorgesehenen Zweck.
Vielleicht könnte für Dir /usr/bin/lockfile dienlich sein. Schau mal die manpage an.
Yo, Jan hat auch eine Lösung mit Lockfiles vorgeschlagen. Er erwähnte aber auch, das diese keine 100%tige Sicherheit bieten, worin Bernd wohl übereinstimmte. Daher hier mein Gedankenspiel, wie sich das 100%ig sicher bewerkstelligen lässt. Das das dann völlig überzogen kompliziert für so eine "Spielanwendung" ist, darin stimme ich mit dir überein. Geht mir mehr darum, ob die theoretische Überlegung stimmt oder ein Denkfehler drin ist. MfG, Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum wrote:
Am Mittwoch, 3. September 2003 09:15 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Hullos,
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
Hmm, bist du da sicher? Das System einer Tokenvergabe sollte sich doch auch unter Linux realisieren lassen. Jan hat mir eine mögliche Lösung über Locks gemailt aber auch geschrieben, das dies nicht völlig sicher ist. Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
Sieht eigentlich gut aus, was Du dir überlegt hast, ist aber ziemlich kompliziert für den von dir vorgesehenen Zweck.
Vielleicht könnte für Dir /usr/bin/lockfile dienlich sein. Schau mal die manpage an.
Yo, Jan hat auch eine Lösung mit Lockfiles vorgeschlagen. Er erwähnte aber auch, das diese keine 100%tige Sicherheit bieten, worin Bernd wohl übereinstimmte. Daher hier mein Gedankenspiel, wie sich das 100%ig sicher bewerkstelligen lässt. Das das dann völlig überzogen kompliziert für so eine "Spielanwendung" ist, darin stimme ich mit dir überein. Geht mir mehr darum, ob die theoretische Überlegung stimmt oder ein Denkfehler drin ist.
MfG, Bernd
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes: A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly B will schreiben, das Token ist aber nun readonly -> Fehler Ist aber sehr an den Haaren herbeigezogen, aber theoretisch möglich. Das Problem, das bei einem "Absturz" eines Prozesses die Token auf einem falschen Status stehen bleiben, war glaube ich schon im Thread und muss meiner Meinung nach unbedingt berücksichtigt werden. Im übrigen ist die Vergabe von fortlaufenden Nummern ein interessantes Programmierer Problem z.B. Das Vergeben von Kundennummern usw. Vielleicht liest ja ein Informatikstudent mit und kennt einen Theoretischen Ansatz. Bisher gieng ich davon aus, das sich das Problem nur sauber und sicher mit Systemen lösen lässt, die ein Locking integriert haben. (z.B. Datenbanken uä.) MfG Werner
Am Mittwoch, 3. September 2003 10:35 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Am Mittwoch, 3. September 2003 09:15 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
[...]
Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
[...]
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes:
A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly B will schreiben, das Token ist aber nun readonly -> Fehler
Ist aber sehr an den Haaren herbeigezogen, aber theoretisch möglich. Das Problem, das bei einem "Absturz" eines Prozesses die Token auf einem falschen Status stehen bleiben, war glaube ich schon im Thread und muss meiner Meinung nach unbedingt berücksichtigt werden.
Hmm, das Problem sehe ich nicht ganz. B kann also nicht schreiben und produziert einen Fehler, das ist doch ok. Im Programmcode lässt sich doch leicht abfangen, ob das Schreibkommando erfolgreich war. Wenn nicht, geht B in Wartestellung bis das Token wieder frei ist und gut ist. Nur weil B nicht schreiben kann, stürzt doch der Prozess hier nicht ab, *überleg*, hm?
Im übrigen ist die Vergabe von fortlaufenden Nummern ein interessantes Programmierer Problem z.B. Das Vergeben von Kundennummern usw. Vielleicht liest ja ein Informatikstudent mit und kennt einen Theoretischen Ansatz. Bisher gieng ich davon aus, das sich das Problem nur sauber und sicher mit Systemen lösen lässt, die ein Locking integriert haben. (z.B. Datenbanken uä.)
Yep seh ich auch so. Also, an alle Informatiker, teilt euer Wissen mit uns. Gibt es da Ansätze ausserhalb von DBs im Linuxbereich? -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum wrote:
Am Mittwoch, 3. September 2003 10:35 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Am Mittwoch, 3. September 2003 09:15 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
[...]
Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
[...]
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes:
A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly B will schreiben, das Token ist aber nun readonly -> Fehler
Ist aber sehr an den Haaren herbeigezogen, aber theoretisch möglich. Das Problem, das bei einem "Absturz" eines Prozesses die Token auf einem falschen Status stehen bleiben, war glaube ich schon im Thread und muss meiner Meinung nach unbedingt berücksichtigt werden.
Hmm, das Problem sehe ich nicht ganz. B kann also nicht schreiben und produziert einen Fehler, das ist doch ok. Im Programmcode lässt sich doch leicht abfangen, ob das Schreibkommando erfolgreich war. Wenn nicht, geht B in Wartestellung bis das Token wieder frei ist und gut ist. Nur weil B nicht schreiben kann, stürzt doch der Prozess hier nicht ab, *überleg*, hm?
Klar Du hast vollkommen recht. Sorry, habe faul wie ich bin nur "Absturz" geschrieben anstatt nachzudenken und genauer zu beschreiben. Ich wollte nur darauf hinweisen, dass da ein Problem entstehen kann. Natürlich stürzt der Prozess nicht ab.
Im übrigen ist die Vergabe von fortlaufenden Nummern ein interessantes Programmierer Problem z.B. Das Vergeben von Kundennummern usw. Vielleicht liest ja ein Informatikstudent mit und kennt einen Theoretischen Ansatz. Bisher gieng ich davon aus, das sich das Problem nur sauber und sicher mit Systemen lösen lässt, die ein Locking integriert haben. (z.B. Datenbanken uä.)
Yep seh ich auch so. Also, an alle Informatiker, teilt euer Wissen mit uns. Gibt es da Ansätze ausserhalb von DBs im Linuxbereich?
MfG Werner
Hi Bernd, Bernd Tannenbaum schrieb:
Am Mittwoch, 3. September 2003 10:35 schrieb Werner Merz:
Im übrigen ist die Vergabe von fortlaufenden Nummern ein interessantes Programmierer Problem z.B. Das Vergeben von Kundennummern usw. Vielleicht liest ja ein Informatikstudent mit und kennt einen Theoretischen Ansatz. Bisher gieng ich davon aus, das sich das Problem nur sauber und sicher mit Systemen lösen lässt, die ein Locking integriert haben. (z.B. Datenbanken uä.)
Gibt es da Ansätze ausserhalb von DBs im Linuxbereich?
Grössere Systeme lösen soetwas durch eine Zwangsserialisierung, sprich man hat einen Daemon der - durchaus auch mehrere aber immer nur einen Thread/Sequenz - hat um eine Sequenz zu erzeugen. Das läuft dann so ab: A will ne Nummer der Sequenz D haben B will ne Nummer der Sequenz D haben ... also fragen sie den Daemon, der Daemon nimmt die Anfragen (durchaus auch mit mehreren Threads) entgegen und fügt sie einer Tabelle hinzu, irgend ein Stück Programm arbeitet diese Tabelle ab und antwortet bzw. lässt antworten. Ein Garbage collector räumt ggf. die Tabelle auf. Dann kann man idr. noch einstellen nach welchen Regeln (Schrittweite, Numerisch/ASCII) diese Sequenz gebildet werden soll. Irgendwo hält das Teil dann noch den aktuellen Stand auf der Festplatte. Das es soetwas nicht als standard Dienstleistung innerhalb eines Unix system gibt ist allerdings schon verwunderlich da die Prozessnummern des Kernels auch von so einem Stück Software gebildet werden müssen. Alle ernst zu nehmenden Datenbanken haben solche Sequenzgeneratoren auch schon intus. hier wäre jetzt zb. auch ein möglicher und praktikabler Ansatz, auf kaum einem Linux System benutze ich die mysql DB nicht, also läuft das Teil eh fast immer, ein stückchen perl was einen autoincrement Datensatz dort hin schreibt und sich die ai nummer rückliest sind nur wenige Zeilen, wenn man das ding zb. mit seq.pl sequenzname aufruft wäre auch eine allgemeingültige Lösung erstellt. Besonders schnell ist das allerdings nicht aber schön einfach und übersichtlich. Aus 1,2,... lässt sich ja per offset und schrittweitenfaktor recht einfach nahezu jede beliebige Auf- und Absteigende Ziffernfolge bilden. Gruss Falk
Hallo, On Wed, 03 Sep 2003, Falk Sauer schrieb: [..]
hier wäre jetzt zb. auch ein möglicher und praktikabler Ansatz, auf kaum einem Linux System benutze ich die mysql DB nicht, also läuft das Teil eh fast immer, ein stückchen perl was einen autoincrement Datensatz dort hin schreibt und sich die ai nummer rückliest sind nur wenige Zeilen,
Boeh, useless use of perl ;) echo "SQL_BEFEHLE" | mysql -u sqluser -p 'sqlpasswort' oder mysql -u sqluser -p 'sqlpasswort' < befehle.sql Allerdings ist das Problem hier ja anders gelagert, denn es soll ja nur ein (eher kleiner) Bereich (20000 bis max. 65534) verwendet werden. -dnh --
2. Ich bin nicht mehr in der fuenften klasse wie du sondern ich bin anerkannter IT - Supporter im Raum Stuttgart. *Prust* Jetzt habe ich schon wieder Kaffee auf dem Bildschirm... [> Marco Tetzner und Antje M. Bendrich in suse-linux]
Hallo David, hallo Leute, Am Freitag, 5. September 2003 00:23 schrieb David Haller:
echo "SQL_BEFEHLE" | mysql -u sqluser -p 'sqlpasswort'
oder
mysql -u sqluser -p 'sqlpasswort' < befehle.sql
Fast richtig ;-) cb@tux:~> mysql -u fontlinge -p geheim Enter password: [...] cb@tux:~> mysql -u fontlinge -pgeheim Welcome to the MySQL monitor. [...] Zwischen -p und dem Passwort darf _kein Leerzeichen_ stehen [1], sonst klappt das nicht (mysql fragt dann das Passwort interaktiv ab) - aber ich dachte, das hättest Du auf fontlinge-devel schon gelernt. Apropos - wolltest Du Dich nicht mal wieder dort melden? Gruß Christian Boltz [1] Im Gegensatz zu -u, dort ist ein Leerzeichen erlaubt, aber nicht zwingend nötig -- Naja, lieber WAMP als WIMA (Windows, IIS, MicrosoftSQL, ActiveScript). Obwohl, das wäre wahrscheinlich ein ganz besonders sicherer Server, weil hinter allen Sicherheitslücken nur abstürzende Programme liegen. "Ich bin drin! Ups, da geht er hin..." };-> [Ratti]
Werner Merz wrote:
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes:
A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly
Falsch. A Setzt Token, A prueft, ob das Token ihm gehoert und schreibt nur dann.
B will schreiben, das Token ist aber nun readonly -> Fehler
B setzt Token, das schlaegt fehl, bzw. die Ueberpruefung, ob das Token B gehoert schlaegt fehl. -- Have fun, Peter
Peter Wiersig wrote:
Werner Merz wrote:
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes:
A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly
Falsch. A Setzt Token, A prueft, ob das Token ihm gehoert und schreibt nur dann.
B will schreiben, das Token ist aber nun readonly -> Fehler
B setzt Token, das schlaegt fehl, bzw. die Ueberpruefung, ob das Token B gehoert schlaegt fehl.
Eine theoretische Frage, da mich das Problem auch interessiert: Obiges mit Ueberpruefung auf Ownership geht aber nur wenn A und B als unterschiedliche User eingelogged sind. Wenn ja, sollte auch das Warten und nochmals Prüfen überflüssig sein. Oder sehe ich das falsch? MfG Werner
Werner Merz wrote:
Peter Wiersig wrote:
B setzt Token, das schlaegt fehl, bzw. die Ueberpruefung, ob das Token B gehoert schlaegt fehl.
Obiges mit Ueberpruefung auf Ownership geht aber nur wenn A und B als unterschiedliche User eingelogged sind.
Oder sehe ich das falsch?
Ich bezog den Eigentuemer auf die Prozess-ID. -- Have fun, Peter
Hallo, On Wed, 03 Sep 2003, Bernd Tannenbaum schrieb:
2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen.
Warum ist dir die PID nicht eindeutig genug? Achso: Pid-/Lock- und aehnliche Dateien gehoeren nach /var: ==== FHS 2.0 ==== 5. The /var Hierarchy /var -- Variable data | +-lock Lock files +-run Files relevant to running processes +-state Variable state information [..] Applications should generally not add directories to the top level of /var. Such directories should only be added if they have some system- wide implication, and in consultation with the FHS mailing list. ==== (der letzte Absatz speziell fuer Jan ;) Der Ansatz von Jan ist gut, ich wuerde sowas in der Art hier verwenden: ==== nur ein wenig getestet ==== #! /bin/sh LOCKFILE="/var/lock/assh.lck" STATEDIR="/var/state/assh" PORTFILE="${STATEDIR}/assh.ports" DEFAULTPORT="20000" LASTPORT="20010" TIMEOUT=60 # Verzeichnis $STATEDIR muss existieren und fuer uns schreibbar sein if test -d "$STATEDIR" && test -w "$STATEDIR" then : else cat <<EOF >&2 No such directory or cannot write in '$STATEDIR' Please contact your system-administrator to create this directory with appropriate permissions. EOF exit 2 fi # und $PORTFILE muss existieren und schreibbar sein test -f "$PORTFILE" && test -w "$PORTFILE" || echo "$DEFAULTPORT" > "$PORTFILE" # bei Abbruch aufraeumen... trap "release_port $port; release_lock;" 1 2 3 15 get_lock() { # Pruefen, ob $LOCKFILE existiert und lesbar ist if test -r "$LOCKFILE" then # wenn die Datei existiert: pruefen ob Prozess noch aktiv ist # wenn ja, dann warten t=1 while ps -p `cat $LOCKFILE` >/dev/null 2>&1 do sleep 1 t=`expr $t + 1` test $t -gt $TIMEOUT && exit 1 done fi # LOCKFILE existiert nicht oder Prozess ist gestorben, (ggfs. anlegen) # und eigene PID reinschreiben echo $$ >$LOCKFILE || { echo "cannot write to '$LOCKFILE'" >&2; exit 2; } } release_lock() { test "x`cat \"$LOCKFILE\" 2>/dev/null`" = "x$$" && rm -f "$LOCKFILE" } get_port() { get_lock || exit 1 used_ports="`cat \"$PORTFILE\" | grep -v '^$'`" if test -z "$used_ports" then new_port="$DEFAULTPORT" else p="$DEFAULTPORT" while echo "$used_ports" | grep -q "$p" && test $p -lt $LASTPORT do p=`expr $p + 1` done if test $p -ge $LASTPORT then echo "All ports in use, please try again later." >&2 exit 1 fi new_port="$p" fi # add new port to $PORTFILE echo "$used_ports $new_port" | sort -un | grep -v '^$' > $PORTFILE release_lock || exit 1 # return new port echo "$new_port" } release_port() { get_lock || exit 1 used_ports="`cat $PORTFILE`" echo "$used_ports" | grep -v "$port\|^$" | sort -un > $PORTFILE release_lock || exit 1 } # freien port finden port=`get_port` # autossh aufrufen /usr/bin/autossh -M $port "$@" # und wieder freigeben release_port $port ==== Ups, grad seh ich ne moegliche "Luecke" (port ist leer) in "release_port()"... Da bin ich jetzt aber zu muede zu... -dnh PS: etwas eigenartige Konstruktionen (if ... ; then : ; else ... ; fi) sind dadurch bedingt, dass ich bourne-shell kompatibel sein will und die ash zum testen verwendet habe -- und deren if-builtin kann kein 'if ! ...' -- We are gathered here today for a solemn occasion, to honor the memory of a good joke which fell victim to a crude, pointless rebuttal by a poster temporarily bereft of sanity and decorum. -- David P. Murphy
Hallo David, hallo Leute, Am Freitag, 5. September 2003 02:38 schrieb David Haller:
#! /bin/sh [...] STATEDIR="/var/state/assh" [...] # Verzeichnis $STATEDIR muss existieren und fuer uns schreibbar sein if test -d "$STATEDIR" && test -w "$STATEDIR" then : else cat <<EOF >&2 No such directory or cannot write in '$STATEDIR' Please contact your system-administrator to create this directory with appropriate permissions. EOF exit 2 fi [...] PS: etwas eigenartige Konstruktionen (if ... ; then : ; else ... ; fi) sind dadurch bedingt, dass ich bourne-shell kompatibel sein will und die ash zum testen verwendet habe -- und deren if-builtin kann kein 'if ! ...'
Ich wage es Dir gegenüber kaum zu sagen, aber: man test ;-) Das richtige Stich"wort" wäre in diesem Fall das Ausrufezeichen. Gerade in der ash getestet # mkdir testdir ; touch test # test ! '(' -d testdir -a -w testdir ')' && echo Problem # chmod 000 testdir # test ! '(' -d testdir -a -w testdir ')' && echo Problem Problem # test ! '(' -d test -a -w test ')' && echo Problem Problem # chmod 000 test # test ! '(' -d test -a -w test ')' && echo Problem Problem BTW: Statt '(' und ')' kann man natürlich auch mit \( und \) escapen. Um nochmal auf das ursprüngliche Script zurückzukommen - der folgende Block funktioniert auch ohne Verrenkungen ;-) # test ! \( -d test -a -w test \) && { echo Problem echo bitte überprüfen exit 3 } Problem bitte überprüfen [3] cb@tux:~> ^^^ ^^^^^^^^^ =$? zurück in der Bash ;-) BTW: Du hast Dir gerade einen useless use of if Award verdient ;-) Gruß Christian Boltz -- [SuSE 8.2] Auch die Paketverwaltung via YaST2 ist endlich einigermaßen brauchbar: Du kannst ein Paket auf ein permanentes "Tabu" setzen und - jetzt kommt die Überraschung - er überschreibt es _wirklich_ nicht! ;-) [René Matthäi in suse-linux]
participants (7)
-
B.Brodesser＠t-online.de -
Bernd Tannenbaum -
Christian Boltz -
David Haller -
Falk Sauer -
Peter Wiersig -
Werner Merz