Der große pkg (ehemals pkgng) Thread

Ich glaube man kann die Reihenfolge bestimmen, wenn man die Repository Dateien, beim Namen sortiert unter /usr/local/etc/pkg/repos speichert:
Code: 
1-poudriere.conf
2-FreeBSD.conf
Ich meine das mal gelesen zu haben...
 
Auf einem neuen Server hatte ich mich unlängst mit pkg angefreundet. Kompiliert wird zwar nach wie vor via portmaster, die Verwaltung der installierten Ports ist jedoch etwas einfacher. Von daher, Daumen hoch!

Sorgen bereitet mir aktuell das Monitoring, ich versuche die Ports wie gehabt mit nagios-check_ports und nrpe2 remote abzufragen. Im Hostsystem gelingt es anstandslos, aber die Prüfung des Jails schlägt fehl:

nrpe2 Kommando
Code: 
command[check_ports_webserver1]=/usr/local/libexec/nagios/check_ports -ap -j webserver1 -u

Befehl
Code: 
/usr/local/libexec/nagios/check_nrpe2 -H 127.0.0.1 -c check_ports_webserver1

Meldung
Code: 
PORTS UNKNOWN - option -u cannot be used with the pkg(8) suite of tools.

Ohne -u kann nrpe das Jail mangels Berechtigung nicht prüfen.

Gibt es dafür ne alternative Herangehensweise?
 
Hi,

installiere geradeeben eine Workstation...

Warum ist es es nicht moeglich pkg in diese Art und Weise zu verwenden?

Bspw.:
---------

# cd /usr/ports/xxx_category/xyz_port
# pkg install .

Wenn diese Funktionalitaet implementiert wuerde, das waere schoen. *traeum* :-)
 
Gerade las ich das NetBSD Support hinzugefügt wurde nun frage ich mich wozu der gut sein soll. Erstens löst dort pkg kein Problem(es gibt sogar 2 Tools die oberhalb von pkgsc aufsetzen) und zweitens setzt doch pkg ports voraus, die es nicht gibt oder keiner nutzt es.
 
Es ist besser zu viel im Angebot zu haben als das jeder für sich entwickelt, so wie es Linux-Entwickler gerne machen (ich will jetzt nicht das böse s-Wort sagen).
 
Ich seh das praktisch.Keiner brauchts bei NetBSD, aber es wird sicher sich irgendwann jemand regen wenn der Support kaputt oder eingestellt wird, vielleicht gehts auch nur durch den Blätterwald . Letztendlich werden da Ressourcen reingesteckt auch wenn es nur bedeutet lasst dieses Feature drin ist, hoffen wir mal es funktioniert noch, aber ohne kritische Masse die das nutzt ist das verschwendete Liebesmüh.
 
Also ich sehe das nicht als verschwendete Lebensmüh. Es gibt pkg, es gibt NetBSD und es gibt viele pkgsrc User (Minix, Solaris (SmartOS)), ... Code zu teilen ist da eher das Gegenteil von Verschwendung. Also in der Hinsicht, dass es eine Annäherung gibt. Gerade wenn ich mir überlege, dass auf der einen Seite (FreeBSD) mehr ports existieren und auf der anderen Seite (NetBSD/pkgsrc) die häufig aktueller sind (subjektive Erfahrung, die sehr wahrscheinlich stark auf der von mir genutzten Software basiert) und ich mir ansehe wie häufig ich Dinge doppelt mache und einen Patch für pkgrc und dann nochmal für ports mache wäre es schon recht cool, wenn man durch Annäherung, aber auch durch Portabilität einem Entwickler an Software X erlaubt möglichst weit zu kommen ohne sich in beide Systeme einarbeiten zu müssen. Es ist ja wirklich so, dass ein Großteil der Unterschiede für einen Port doch sehr marginal sind, zumindest, wenn die Software eigentlich auf jedem POSIX-System funktioniert.

Ich sage ja nicht, dass der Aufwand ganz weg wäre oder so, aber gerade solche Portabilitätssachen machen oft viele Türen auf und bescheren Entwickler, Ideen während die Kosten oft minimal sind, gerade wenn es nur um ein weiteres unixoides System geht. Auch glaube ich nicht das NetBSD jetzt umsteigt, es einen Merger gibt oder ein großes gemeinsames Projekt. Es ist nur so, dass Optionen häufig ungeahnte Möglichkeiten schaffen. Ich glaube nicht, dass der NetBSD-Support irgendwie teuer erkauft war oder die Maintenance ein großer Punkt wird, zumal pkg ist ziemlich gut designed ist.

Sorry, das war jetzt mehr erfahrungsbasiert, als objektiv. Aber die Portierbarkeit von Software ist in vielen Fällen eine Sache, die mit guter Qualität und gutem Software-Design einher geht.
 
pkg, pkgin und nih machen dann praktisch alle dasselbe wenn vermutlich die pkgsrc-Dinger einen andere Bibliothek drunter benutzen als pkg. Keines löst die Probleme das man Packages mit eigenen Optionen irgendwie in die Datenbank bekommt. Der verlinkte Thread macht das auch nochmal deutlich. Pkg löst Usability-Probleme im FreeBSD bei den pkg_*-Tools. Es besteht kein Featurenotstand. Nicht mal die zwei genannten sind Bestandteil der CD auch der Installer ignoriert fleißig die Tatsache das deren Datenbanken schnell die Partition verstopfen. Ich weiß gar nicht warum OpenBSD noch kein pkg nutzt. Unter den Nutzer von pkgsrc ist es noch nicht überall angekommen, das pkg_* für reinen Binarybetrieb nicht ohne Schmerzen zu betreiben ist.
Das Problem das jede Software trotzdem noch Anpassungen braucht und wenn es das Zurechtrücken der Pfade der Libs und Tools ist, besteht weiterhin. Der Rest ist zumeist eine Endlosorgie an separaten Patches für OSe um den Bau zu unterstützen, die Hälfte gehört da sicher Upstream und nicht in pkgsrc, aber das löst auch nicht pkg. Ich würde mir da wünschen man würde unbürokratisch und via github da rangehen statt cvs und Mailinglisten zu pflegen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben