NetBSD base und userland (war: Warum ist NetBSD so einzigartig?)

T

tib

Guest
Wozu mehrere Ablageorte für Konfigurationsdateien?

.
 
Zuletzt bearbeitet von einem Moderator:
Das ich (bei FreeBSD) rm -rf /usr/local mache und wieder ein (fast) sauberes System habe ;-)
 
tib schrieb:
Wo liegt der Mehrwert für einen Nutzer wenn er an mehreren Orten nach den Konfigurationsdateien suchen muss?

1. Man muss nicht suchen, ist es im Basissystem, ist es in /etc, ist es ein Paket, ist es in /usr/pkg/etc

2. Wie trennt man deiner Meinung nach die Konfigdateien von Programmen die im Basissystem und in pkgsrc sind? Bspw. sendmail, postfix oder ssh?

3. Wenn das System konsequent Ordnung hält, muss man nicht suchen und kann so bequem Pakete verwalten. Anders als wenn jedes Paket seine Dateien hinwirft wo es grade Lust hat.
 
tib schrieb:
Dann muss ich eben herausfinden, ob ein Programm im Basissystem oder in pkg ist.
Wo ist der Unterschied?

Welcher Unterschied?
tib schrieb:

Du scheinst wenig Ahnung von der Paketverwaltung zu haben, wenn du Basisprogramme und Pakete nicht trennst, wie willst du sie dann konfigurieren?

Warum sollten irgendwelche Konfig-Dateien von irgendwelchen Paketen im Basissystem rumdümpeln?

tib schrieb:
Ich habe nichts gegen eine Trennung Basissystem und Paketen.
Aber ich habe hier noch nie eine wirklich Begründung erhalten,
warum das Basissystem nicht ebenfalls in Form von Packeten vorliegt.

Es heißt Pakete und nicht Packete.

Das Basissystem ist nicht in Paketform weil es unnötig ist es in Pakete zu packen. Es wird installiert in dem man die Sets vom Band rüberkopiert oder mit tar entpackt. Der ganze Kram wie Sysinst ist neumodischer Schnickschnack und vergleichsweise neu. Mal ganz davon abgesehen das es noch Architekturen gibt wo sysinst nicht tut.


tib schrieb:
Du meintest "wer"?

Was? Ich verstehe nicht was diese Frage soll.

tib schrieb:
Korrekt, aber das sollte schlieslich das Packetierungsystem hinbekommen,
wobei der Pfad egal sein sollte, also auch /etc.

Das Paketsystem ordnet die Pakete in dem es sie vom Basissystem trennt. Schonmal daran gedacht das /var korrumpiert sein kann? Was dann?


Schonmal mit einem Solaris gearbeitet? Da wird die Trennung noch signifikant weiter getrieben. Und das ist auch gut so.
 
Die Diskussion führt doch zu gar nichts!
( Ok Da nun durch verschieben wieder on Topic, ist diese Aussage umrelevant )

Fakt ist, das es irgend wie getrennt werden muss im Sinne von,
x ist erst mal Basis und gehört zu einer Standard Installation dazu.

Fakt ist auch, das dies irgend wer entscheiden muss.
Das man sich hier trefflich streiten kann was ins Base gehört, ist auch ein Fakt.
(Schaut man sich nur die FreeBSD-Diskusion Sendmial, Bind im Base an.)

Und natürlich ist da nicht jedes *BSD gleich.
OpenBSD hat zum Bleistift ein Apache im Base.

Natürlich kann das verwirrend sein.
Beschäftigt man sich damit aber eine weile,
wird man feststellen das, dies alles schon sein Logik hat.
Da die Schwerpunkte der einzelnen BSDs auch verschieden sind.

Der nächste Fakt ist, das Dir kein BSD* Vorschreibt was Du schlussendlich machst.
Ich kann nur für FreeBSD sprechen, aber da kann ich selbstverständich,
sehr einfach ganze Teile vom Base weglassen, wenn ich das für Nötig halte.

Weiter geht es mit den Pakten.
Keiner zwingt dich diese zu verwenden.
Willst Du das aber, dann muss man nun mal mit den Spielregeln leben,
die da mal aufgestellt worden sind.

Sonst hättest man ja keine Ordnung und könnte sich
diese »unötigen« Pakete, Ports einfach schenken ;-)

EDIT: abgeändert da Verschoben...
 
Zuletzt bearbeitet von einem Moderator:
Eine schwere Frage, was ins Basissystem gehört und was nicht. Früher zeichneten sich UNIX-Kisten mal dadurch aus, dass sie mit möglichst vollständiger Ausstattung - obwohl nicht aktiviert - daherkommen. Heute würde jeder vernünftige Admin Telnet, FTP, YP und die r-tools als Beleidigung empfinden.

Offen gesagt, halte ich nen gewissen - zeitgemäß angepassten - Standardsatz an Tools&Services für sinnvoll und angemessen. Ich will schon SSH&Co vorfinden, wenn ich nen fresh-Install durchführe. Aber wo die Grenze ziehen? Muss auf jeder Kiste ein remote-zugänglicher MTA drauf?

Irgendwie kocht da jeder sein eigenes Süppchen. Irgendwie ist das auch alles Fragwürdig. Ich hab aber keinen Bock, ständig am kleinsten gemeinsamen Nenner zu sitzen (= kann gar nix) und Zeuchs nachzuziehen.

Gruss,
hirnzerfall
 
Hallo allerseits,

da sich der Tread "Warum ist NetBSD so einzigartig?" doch etwas abweichend vom Topic entwickelt hat wurde das Ganze aus Übersichtlichkeitsgründen gesplittet.

Gruss,
Thomas
 
tib schrieb:
Es sind bei FreeBSD selbst bei einer Minimal-Installation die von hinzerfall erwähnten Programme enthalten.
Wenn Du sie nicht explizit aktivierst, braucht man sich doch keine Sorgen um diese Programme zu machen, oder? Und wenn Du sie trotzdem nicht willst, dann hindert dich niemand daran, eine "Custom Installation" durchzufuehren :)
 
tib schrieb:
Warum sollte ich mir überhaupt von einem Betriebssystem vorschreiben lassen was ins Basissystem gehört und was nicht?
Naja, wenn Du ein System installierst, dass sich eben genau dadurch definiert, dann wirst Du das wohl in Kauf nehmen müssen. Bei Windows fragt auch keiner, warum er sich was installieren soll, das nicht ohne grafische Oberfläche daherkommen kann. Und bei Linux will auch keiner wissen, warum das Betriebssystem vorschreibt, ohne jegliches Zubehör daherzukommen.
 
Der MTA wird soviel ich weiß für zwei Dinge verwendet: Die Status- und Securityberichte und Cron. Vielleicht auch noch etwas Anderes. Aber die Drei Dinge (MTA, Cron, Statusreport) sind ja prkatisch von einander abhängig. Bei NetBSD ist, wenn ich das richtig verstanden habe, X ja mehr oder minder ein Aufsatz bzw. Zusatz. Es ist ja in xsrc..
Viele installieren es garnicht mit (bei DragonFly, das ja auch pkgsrc verwendet ist es gar nicht dabei) und installieren xorg dann aus pkgrsc.

Ein festes Grundsystem hat einige Vorteile: Das (Grund)System kompiliert für gewöhnlich prima mit dem Compiler, der im Grundsystem ist. Wenn man eine sichere (sprich es gibt weder nen Mittelmann, der zum Beispiel umleitet, noch wurden die Datein dort modifiziert) Quelle hat, dann kann man sich sicher sein, dass alles sicher ist. Wenn ich jetzt jedes Programm von nder anderen Seite lade (also ein Portsystem verwende) muss ich mir überall sicher sein. Der Sourcecode der wichtigsten Sachen wird zumindest vom (hoffentlich fähigen) Committer geprüft. Fehler (jetzt nicht nur im Code, sondern wenn mal halt nicht funtzt, werden bei wichtigen Dingen (also das Zeug in Base) werden wenn man die selbe Base hat leichter ausfindig gemacht (vielleicht kann man das mit "Warum man den GENERIC-Kernel bei OpenBSD verwenden sollte" vergliechen).

Mit nem Basissystem hat man nicht gleich mit welches Programm nehm ich für XY.
Du hast mail, als Mailprogramm, ich glaube pixiecron, als cron, syslog für die Logs, bei OpenBSD lynx als Browser, mindestens einen Editor, mindestens einen MTA, so wie gute Standardtools, die abhängig von den Entwicklern des jeweiligen BSDs (und nicht von nem port-/package-Maintainer) sind, wie OpenSSH, telnet, ..

Wenn was nicht funtzt wird bei Problmen für gewöhnlich nicht die Schuld beim Anderen (Betriebssystem-Entwickler, Portmaintainer, Projekt der betreffenden Software) gesucht -> Du hast eine Ansprechperson (oder Personen), bzw. eine Mailingliste.

Das kam mir heute wieder zugute, weil ich was über die (ganz neu! UPDATEN!!! Lücke) in OpenSSL gelesen habe. An DragonFly (im IRC) gemeldet, kurz gewartet und gepacht wars. Hmm.. soll ich das in die News schreiben? NetBSD hab ich's auch schon gemeldet, die arbeiten dran. Wissens Free- und OpenBSD schon?
 
Zurück
Oben