[linux-l] rpm's bauen

[Olaf Radicke]

Am Montag, 19. Februar 2007 schrieb Volker Grabsch:
> 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. 

Das Programm verbindet sich immer über Socket mit der DB. Egal wo sie 
läuft. Also muss die DB 1.) auf Socket lauschen und 2.) eine Verbindung 
darüber zulassen. Beides tut Postgres "out of the Box" nicht. Da musst 
du mindestens zwei Config-Datei editieren, den DB-Server neu starten und 
ggf. die Firewall anpassen.

> 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.

Im meinen Fall sogar zwingend. Da ja mehere Leute auf einer DB-Instanz 
arbeiten können/sollen.

> > 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.

Bei PHP-Progs kann ich mir mittlerweile fast alles vorstellen ( aber 
lassen wir das ;-))

> > 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.

Hhhmmm? Warum sollte mir eine DB ihrer Passwörter verraten? Dann wären 
Passwörter witzlos.

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

Das hat nichts mit der DB zu tun. Das ist meine Konfiguration. Die von 
Anderen kann wieder anders aussehen.

> 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.

Schieben wir das Problem erst mal nach Hinten...

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

Wie oben schon erklärt. Es kann sein das DB-Root kein 
Passwort-Authentifizierung hat.

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

Windows-Programmierer auch? Die kennen doch meist nicht mal emacs und 
gcc.

> > > 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 man eine hat :-)

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

Hast wohl Recht.

> > 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 der Rest der Doku bleibt in dem Paket?

> > > 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.

Die Npgsql.dll's sind 'nur' unter Windows ein Krampf. Unter Linux sind 
die richtigen Standard mäßig im Mono-Paket drinnen.

Aber ich bin im Zweifel, ob das Paket eine Mono-Abhängigkeit haben 
sollte. Wenn der User immer die Neuste Version von Mono installiert, 
weiß RPM nichts davon und der User ärgert sich, das mein Paket auf eine 
alte RPM-Version beharrt. 

> > > 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?

Vielleicht will der User sein Programm auf einen USB-Stick speichern und 
im Internet-Cafe arbeiten - was dann?

> > 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.

Wie schon gesagt...USB-Stick.

> > 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?

Text-Dateien und Icons.


> > > 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 bist frei geschaltet.

> > 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.

Okay. Das bedeutet wenn du was verschieben willst kannst du das *leider* 
nicht mit copy, sondern du musst das Element exportieren, und an der 
Neuen stelle wieder dem SVN bekannt machen. Dabei geht die ganze 
History verloren. Deswegen wie bei cvs einen Vermerk in's Log wo das 
gute Stück mal her kam. Danach das Objekt am Ursprungsort löschen.

> > 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

if os.name == 'posix':

Wenn ich das richtig verstanden habe, gibt es eine solche Klasse mit 
einer solchen Eigenschaft nicht. Man kann glaube ich nur raus finden 
welche Windows-Version läuft.

Vielleicht erreicht man das selbe, in dem man einfach testet, ob es 
ein "/etc" gibt. Gibt es das, geht man davon aus, ein Linus, BSD oder 
MacOS zu haben.

In .Net gibt es dann noch solche Geschichte...
  Application.UserAppDataPath

Die Zeile...
Console.WriteLine
(
   "### Application.UserAppDataPath: " 
   + Application.UserAppDataPath
);

Gibt bei mir (unter Linus) zurück....
### 
Application.UserAppDataPath: /home/or/.config/artikel_23/artikel_23/0.0.0.0

Mehr dazu...
http://msdn2.microsoft.com/de-de/library/system.windows.forms.application.localuserappdatapath(VS.80).aspx

Gruß
Olaf