[linux-l] rpm's bauen

[Volker Grabsch]

On Mon, Feb 19, 2007 at 12:36:39AM +0100, Olaf Radicke wrote:
> Am Sonntag, 18. Februar 2007 18:02 schrieb Volker Grabsch:
> >
> > ACK. Die GUI muss also beide Bedürfnisse befriedigen. Das ist auch
> > nicht schwer, da kann man sich von den gängigen "Installern" der
> > Web-Applikationen was abschauen.
> 
> Der Vergleich ist unfair. Die Web-Applikationen arbeitet über Apache, 
> der (in der Regel) ausreichende Rechte für die DB hat (wenn nicht 
> gerade SELinux scharf gemacht wurde).

Nein, eher nicht. Auf unsicheren Systemen mag es ja sein, dass alle
CGI-Scripte mit den Rechten des Webservers laufen, aber es geht auch
ohne.

In Postgres kannst du jedem User-Account nen eigenen Postgres-Zugang
und ne eigene DB spendieren. Ohne Probleme. Und so macht man das
normalerweise auch, wenn man IDENT-Authentifizierung macht. Da kommen
die Install-Scripte der Webapplikationen also auch nicht drum herum.

Postgres kann aber auch Passwort-Authentifizierung, d.h. du kannst
beim Einloggen in die DB auch einen anderen Usernamen angeben, brauchst
dann natürlich das Passwort.

> Meine Applikation hat nur die Rechte des Users, der sie ausführt. Und 
> ich hoffe der ist nicht "root", nicht "postgres" oder "apache" bzw. "httpd".

Ich wüsste nicht, dass es üblich ist, dem Apache-User besondere DB-
Rechte zu geben.

> Ich muss also ein extra Tool machen, das der User mit peviligierten 
> Rechten startet. 

Oder dein Tool fragt einfach das Passwort des DB-Admins ab, und regelt
das selbst. Und zwar ohne User-Wechsel, sondern handelt es direkt mit
der Datenbank aus.

> > Okay, super. Nur, um Missverständnissen vorzubeugen, schlage ich
> > folgendes vor (vielleicht machst du das ja schon so):
> >
> > Zwei Möglichkeiten der DB-Einrichtung:
> >
> > * Neue Datenbank anlegen:
> >     Pflicht-Eingabefeld: DB-Root-Passwort
> 
> Bei mir z.B. hat DB-Root kein Passwort. Ich mache unter root ein su zu 
> postgres und lokal unter der Benutzerkennung "postgres" kann ich auf 
> die DB ohne Authentifizierung zugreifen.

Stimmt nicht. Du kannst ohne Passwort zugreifen, aber nicht ohne Auth.
Die Auth. geschieht in deinem Fall passwortlos, weil der Besitzer deines
Prozesses stimmt (aka IDENT-Auth.)

> DB-Root kann weder über 
> Netzwerk kontakten, noch kann er sich direkt lokal einlogen.

Ach, richtig, weil der Postgres-User ein gesperrtes Passwort hat.
Hach Mist ... da ist die Geschichte in MySQL aber einfacher ...

Ein Install-Hook-Script hätte hier auch das grundsätzliche Problem,
dass es nicht weiß, für welche(n) User es ne DB einrichten sollte.
Die Installation ist definitiv der falsche Ort, um die DB anzulegen.

> Ich glaube das einzige Tool was fehlerfrei arbeitet, wäre eines das ein 
> Fenster auf poppen lässt in dem steht "Wir freuen uns, das sie unsere 
> DB-Anwendung verwenden wollen. Leider ist 
> Klassen-Bibliothek 'System.Glaskugel.DBInstall' noch unvollständig. 
> Solange fragen sie bitte ihren DB-Guru ihrer Nachbarschaft um Hilfe. - 
> Vielen Dank!"
> 
> :-)

Nee, so schlimm ist es nicht. Frag doch einfach das Root-Passwort
ab, für die, die die DB automatisch angelegt bekommen wollen.

> > Ausgangspunkt sind die "pristine sources" AKA "upstream sources".
> > Also dein Source-TGZ. Das ist unsere gemeinsame Schnittstelle.
> >
> > Ich sehe, du bietest nur ein Source-ZIP an:
> >    
> > http://belnet.dl.sourceforge.net/sourceforge/artikel23/artikel23-src-
> >0.2.2.zip Na gut, dürfte auch gehen.
> 
> Bitte immer im Hinterkopf behalten: Zielplatform ist Linux, MacOS UND 
> Windows. Zip kennen viele WinUser. Tar....

Zielgruppe für den Quellcode sind Programmierer. Die kennen auch TarGZ.

> > Das hast du bei "artikel23-src-0.2.2.zip" nicht 
> > mitgeliefert! Mir scheint, du hast nicht den Sinn und Zweck von
> > separaten doc- Paketen begriffen: Sie enthalten nicht die *ganze*
> > Doku, sondern den *optionalen* Teil der Doku.
> 
> In erster Linie war es "Lieblosigkeit" und "schlampigkeit". Die ODT-Doku 
> (bzw. PDF) ist eigentlich die wichtigste, die auch eigentlich immer 
> dabei sein sollte. Nur kam mir die Überlegung, das vielleicht Leute 
> zunächst nur die Doku sehen wollen, bevor sie sich den Rest ernsthaft 
> ansehen.

Dafür gibt es Webseiten.

Wenn es sich ein User extra runterlädt und auspackt, meint er es
schon "ernst", wird sich also gleich das Programm ziehen.

> Also hielt ich es für eine gute Idee das getrennt zu machen. 
> Ist aber wahrscheinlich unsinnig, weil die meisten User probieren um 
> dann fest zu stellen, das sie nicht weiter kommen und DANN erst die 
> Doku ansehen.
> 
> Bleibt die Frage wo hin mit der ODT/PDF-Doku? In /src/doku? 

Wieso nicht?

Und in die Binary-ZIPs kommt es auch mit rein ... kopiert .. ist
ja nichts ungewöhnliches, normalerweise liegt das Benutzerhandbuch
im src-Paket als Texinfo, LaTeX oder sowas vor, und im Binary-Paket
dann entsprechend als PDF/HTML/manpage.

> > und z.T. darin, dass es ein 
> > Shell-Script und kein Makefile ist (im Makefile kannst du Variablen
> > verwenden, und deren Wert *von außen*, per Kommandozeilenparameter,
> > ändern).
> >
> > Eine leichte Abhilfe wäre, wenn du statt
> >     /opt/mono-1.2.2.1/bin/gmcs \
> > einfach
> >     gmcs \
> > schreibst, und bei dir zu Hause das Verzeichnis
> > "/opt/mono-1.2.2.1/bin" mit in $PATH aufnimmst.
> 
> Mit zwei gleichnamigen Compiler wird das so nicht klappen. Es ist auch 
> nichts ungewöhnliches unter Mono-Usern mehrere Mono-Installationen zu 
> haben. Mono entwickelt sich so rasant schnell, das die Mono-Version der 
> Distribution nur für die Distrebutionseigenen Progs benutzt werden.
> 
> Deshalb auch die "artikel23.sh". Das kann der User das Verhalten noch 
> etwas anpassen an seine lokalen Verhältnisse.

Gute Idee, aber leider sehr unpraktisch. Um davon weg zu kommen, wurden
irgendwann Make erfunden (.. okay, das hatte noch andere Gründe ;-))
und später configure/make verwendet.

> Und wenn er eine neue 
> Version drüber bügelt, wird die alte "artikel23.sh" nicht gelöscht. 
> Also ein workaround. Aber ich klebe nicht an der Lösung.  


Der übliche Ansatz lautet, ein portables Build-Script bzw. Makefile
zu haben, und dann ein eigenes Script, das nicht im Repository liegt,
und das allgemeine Tool auf dein konkretes System anwendet, z.B.:

Du hast ein halbwegs portables Makefile im SVN-Repository, das unter
anderem folgende Zeile enthält:

    GMCS = gmcs

Dein eigenes "ausprobieren.sh", das nicht im SVN-Repository liegt,
sähe dann etwa so aus:

    #!/bin/bash
    make GMCS=/opt/mono-1.2.2.1/bin/gmcs
    /opt/mono-1.2.2.1/bin/mono artikel_23.exe

Ein normaler User würde stattdessen manuell eintippen:

    make
    mono artikel_23.exe

> > und mit
> >     make run
> >
> > das Programm startet (und ggf. vorher compiliert)?
> 
> Das ist nicht mal nötigt. Das übliche "make install" wäre noch 
> interessant.

Stimmt. Und zwar eines, dass zur Abwechselung mal ordentlich nach
/opt installiert, und nicht krankerweise nach /usr/local/  :-(

> > > Kann ich nicht einschätzen, ob das ein User u.U. schon überfordert.
> > > Ich glaube kitzlig ist, herauszufinden welches der Pfad zur Runtime
> > > ist, bzw. wenn es mehere gibt, welche die richtige ist.
> >
> > Der Normal-User wird nur *eine* Runtime haben, oder?
> 
> Kommt wahrscheinlich darauf an, wie exzessiv er schon dotnet-programme 
> benutzt. Ob er die seiner Distribution benutzt oder die vom 
> Mono-Projekt und da wiederum, ob er den Mono-Installer benutzt oder die 
> rpm's.

Das RPM-Paket sollte mit dem Mono-RPM-Paket zusammenarbeiten, und
erstmal mit niemanden sonst. (wäre sonst auch reichlich sinnlos, so
ein RPM, wenn es von nicht-RPM-Paketen abhängig wäre)

Auch die Dependencies würden dann so gestaltet sein, dass es vom
Mono-RPM und dem npgsql-RPM abhängt. Deren genaue Namen müsste ich
aber mal in Erfahrung bringen.

> > Und die Auswahl der Runtime kannst du doch selbst über $PATH regeln,
> > wozu also überhaupt Aufwand darein stecken?
> >
> > BTW, zu deinem Start-Shellscript:
> >     cd ;
> >     mono /opt/artikel_23/artikel_23.exe;
> >
> > Das ist in keiner Weise portabel.
> >
> > 1. Wieso wechselst du in das Homeverzeichnis des Users?
> >    (kann das dein Programm nicht selbst rauskriegen?)
> 
> Es gibt kein /home bei Windows.

Okay, dann siehe oben. Könntest du solch einen Mechanismus bei dir
einbauen?

> Das Programm sucht eine Konfigurations 
> Datei (die sonst irgendwo sein könnte) im aktuellen Verzeichnis. Das 
> hat Vor- und Nach-teile. 

Aktuelles Verzeichnis hat *sehr* viele Nachteile.

> Aber es kommt noch "schlimmer". Das Programm erwartet seine 
> system-Dateien (die es für alle User verwendet), in den Pfaden...
> 
>   /opt/artikel_23/*
> oder
>   ./*
> 
> Wenn rpm die wo anders abwirft, muss ich halt noch anpassen.

Was genau sind deine System-Dateien?

> Unter Windows liegt die exe und der Rest immer zusammen. Da reicht der 
> Pfade "./*". 

Nein, das gilt nur, wenn es im selben Verzeichnis gestartet wurde.
Auch hier wäre sowas wie %PROGRAM_FILES\artikel_32\... sinnvoll.

> > 2. Was soll der absolute Pfad? Trag doch bei dir zu Hause
> >    /opt/artikel_23 mit in $PATH ein, dazu ist es schließlich da.
> 
> Eine .exe ist erstmal nicht ausführbar unter Linux.

Ich sprach vom artikel32.sh-Script.

> Man kann Konqueror 
> so einstellen, das er alle .exe mit mono startet. Deshalb war die exe 
> nicht in $PATH. Wenn du "artikel_23.exe" in der bash startest bekommst 
> du (im besten Fall) die Meldung: 
> 
> install the Windows version of Mono to run .NET executables

Richtig. Deshalb würde ich auf jeden Fall ein Shellscript namens
"artikel_23"  (ohne Endung .sh) nach /usr/bin/ packen. Hat sich bei
Python-Programmen ebenfalls bewährt ... obwohl ich da öfters auch
ein kleines Python-Script statt Shellscript nach /usr/bin packe ...
ist ja Wurscht, hauptsache, die #!-Zeile stimmt.

> > Zusammenfassend:
> > Ich würde dir gern ein RPM bauen, hätte ich heute auch getan! Aber
> > dazu musst du deine Sources und Pakete erstmal aufräumen.
> > Oder mir Zugang zum SVN geben, damit ich das selbst machen kann.
> 
> Ist Okay. 
> Hast du ein sf.net-Account?

Ja. "vog"

> Du weist das der sche** SVN-Copy-Befehl bei SF.Net nicht funktioniert?

Nein, sorry, das letzte Mal, als ich richtig aktiv SF-Projekte hatte,
da war 11.-12. Klasse ... damals bot SF.net gerade mal CVS an.

> Sagst du vorher noch an was genau du tun willst? Es gibt noch ein 
> zweiten Entwickler (Schwerpunkt Windows) der informiert werden sollte.

Erstmal: Makefile und Start-Shellscript schreiben.

Alles andere geschieht separat über die .spec-Datei. Die kann ich
mit ins SVN hauen oder auch nicht. (eigentlich, vom Konzept her,
gehört sie nicht mit rein, weil sie genaugenommen Distributions-
spezifisch ist, aber die meisten packen sie trotzdem mit rein,
und packen sie sogar sinnloserweise mit in ihr Source-TGZ ...)

Ordentliche Pfade zu den Config-Files etc. müsstest du machen,
ich kenn mich mit C# nicht aus. Du hast ja funktionierenden
Python-Code als Vorlage:

    http://wiki.python.de/Profilpfad_herausfinden

BTW, in dem Zusammenhang ist vielleicht noch folgender Artikel
interessant für dich:

    http://wiki.python.de/Pfade_f%C3%BCr_Dateien


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR