OpenBSD, FreeBSD: votre philosophie de mise à jour?


14

J'utilise FreeBSD depuis environ 5 ans - serveur / bureau - et j'ai tendance à prendre mes habitudes de mise à niveau apt-get / yum avec moi (j'administre également des boîtes Debian / RHEL / Cent - je sais, je savoir ... devrait être plus exigeant quelle que soit la plate-forme). C'est donc généralement:

portsnap fetch
portsnap update
portmanager -u

Pour les ports

Parfois suivi d'un:

freebsd-update fetch
freebsd-update install

Pour le système ... etc. Ensuite, nettoyez tout gâchis par la suite ... s'ils se produisent.

Je réalise que c'est une façon non excessive de faire les choses sans BSD. Quelle est votre philosophie pour vos boîtiers BSD? Exécutez-vous un portaudit / portversion - vérifiez la sortie puis mettez à jour (faites la désinstallation ... etc) après un examen attentif?

Je suis assez nouveau sur OpenBSD, je l'avoue. Je me vois cvsupping l'arborescence des ports, exécutant le script "obsolète", puis juste la mise à niveau des ports critiques --- mais en laissant le noyau / binaires seul et juste la mise à niveau tous les six mois. Avez-vous patché / recompilé / reconstruit le noyau, les binaires --- pourquoi?

Quelle est une approche conservatrice pour les services essentiels (raisonnablement critiques - ce n'est pas une banque ou un hôpital) sur les boîtiers BSD? Utilisez-vous une approche similaire sur vos boîtiers Linux? Je ne touche généralement le noyau sur aucun serveur, sauf si une alerte de sécurité a semé la terreur dans mon âme.

Oui, il y a des documents et des livres à gogo - que faites-vous réellement? En supposant que nous connaissons les bases - quelle est la sagesse? Les cas d'utilisation / environnements et scénarios varient, de même que les enjeux / parties prenantes / utilisateurs. Les livres et les pages de manuel couvrent les outils et utilisations, mais manquent d'application pratique. Recommandez un livre si vous en connaissez un qui le couvre!

Merci d'avoir lu!

Bubnoff

Conclusions ~ Merci à tous ceux qui ont pris le temps de répondre à ce message. Dans l'ensemble, ma stratégie est maintenant de suivre les listes de diffusion pour les deux BSD et d'être plus sélectif / discernant avec la mise à jour que je ne l'ai été par le passé.

FreeBSD ~ Portaudit est une bonne réponse. Avec les listes de diffusion et les audits diligents, je pense que cela servira bien ici. Il est intéressant de noter l'accent mis sur les ports entre OpenBSD et FreeBSD.

OpenBSD ~ suivra la liste de diffusion et utilisera les outils de package (pkg_info et pkg_add -u) lorsque jugé critique. Mises à niveau: il semble que vous devez mettre à niveau au moins une fois par an. Ils prennent en charge la dernière version plus une version de retour - donc en ce moment c'est 4.8 et 4.7.

Merci encore.

Réponses:


9

Assurez-vous de vérifier régulièrement vos ports installés pour les packages vulnérables: portaudit -Fda


1
C'est un must-have pour * BSD. Je recommande fortement de jeter ceci dans une crontab nocturne pour vous envoyer un e-mail chaque matin avec des ports avec des correctifs de sécurité.
Andrew M.

1
Mais alors il s'agit d'agir sur les conseils de Portaudit. En lisant les réponses ici, la plupart des gens conseillent de laisser les choses tranquilles à moins que cela ne soit absolument nécessaire. J'ai entendu des administrateurs affirmer que tout devrait être à jour en permanence ... cela me semble être un bon moyen de casser les choses.
Bubnoff

Je vais suivre ce conseil pour FreeBSD. Je vous remercie. Ce qui laisse OpenBSD
Bubnoff

4

Je ne suis pas sûr qu'il existe une "méthode BSD" spécifique pour faire ce genre de choses. Tout se résume à savoir ce qui est mis à jour et testé - des trucs sysadmin génériques. Heureusement, freebsd-update et portsnap rendent le "savoir quoi" assez trivial.

Mais, puisque vous avez demandé des détails, à l'époque où j'ai rassemblé un grand nombre de machines FreeBSD, elles étaient toutes des nœuds dans un cluster. Les machines autonomes ne seraient pas si différentes de cela, mais je suppose que vous pourriez faire cela vaguement "devops" comme pour vos services de production. Au final, c'est toujours une bonne idée d'avoir des environnements de test et de production séparés.

En situation de cluster:

  • Chaque machine a monté les ports / usr / src , / usr / obj et / usr / via NFS.
  • En fonction de votre budget, vous pouvez soit disposer d'une machine de transfert / génération, soit désigner un nœud de cluster comme nœud de transfert / génération.
  • Le nœud intermédiaire avait une copie différente de / usr / ports
  • Le nœud intermédiaire mettrait à jour src-all et ports-all via cvsup tous les soirs
  • En cas de mise à jour nécessaire, le nœud intermédiaire serait retiré de la rotation et buildworld , installworld et portupgrade seraient exécutés.
  • Le nœud intermédiaire serait testé minutieusement.
  • / usr / ports seraient échangés sur l'hôte NFS
  • Chaque nœud de cluster serait tourné vers l'extérieur, installworld et portupgrade , testé puis retourné.

Évidemment, c'était dans le cas à la fois d'un système et d'une mise à jour des ports, mais la procédure était assez similaire pour mettre à jour uniquement les packages ou le système.

Si cela est fait avec deux machines, vous pouvez avoir chacun à tour de rôle une production ou une mise en scène, ou simplement mettre à jour la production à partir de la mise en scène.

Vous pouvez suivre les modifications à partir des journaux cvs et vérifier si vous avez obtenu des mises à jour spécifiques dans / usr / src / UPDATING et / usr / ports / UPDATING , les deux étant automatiquement mis à jour à partir de cvsup .

Si vous n'utilisez pas cvsup (et de nos jours il y a moins de raison de le faire), vous aurez juste besoin de trouver un autre moyen de suivre les mises à jour que vous souhaitez. Vous pouvez envoyer une liste des modifications que freebsd-update souhaite vous apporter et garder un œil sur la page des errata de sécurité.


J'aime l'idée de «mettre en scène» la «production» des versets. Avec la virtualisation, il n'y a presque aucune excuse à ce jour. Merci pour la réponse.
Bubnoff

Ouais, en plus ça s'intègre bien avec les trucs de type 'devops' (d'après ce que je comprends) si vous avez à gérer cela.
DF

4

OpenBSD Update Philosophy

Voici mon approche pour la mise à jour d'OpenBSD

Restez à jour sur les versions / correctifs de sécurité pour:

  • BASE (c'est-à-dire les éléments que l'équipe de développement OpenBSD conserve dans son arborescence source)
  • Packages / Ports (c'est-à-dire applications logicielles installées sur BASE)

Procédures de mise à jour:

  • Même version du système d'exploitation
  • Nouvelle version du système d'exploitation

BASE

une. Suivez les listes de diffusion pertinentes - Je regarde les résumés quotidiens de squish.net, ainsi que la direction générale indiquée sur les listes de diffusion Tech et Divers.

b. Suivez les sites Web / listes de diffusion d'annonces de sécurité liés à Unix.

c. Maintenir une copie CVS locale de l'utilisation de cvsync

ré. Créez des versions STABLES à partir de ce qui précède

Lorsque des mises à jour de sécurité sont publiées, nous évaluons le problème de sécurité réel avec le profil des machines avec cette version du système d'exploitation / vulnérabilité. Si la vulnérabilité est pertinente, nous suivons la «même procédure de mise à niveau de version».

Packages / Ports

Il est plus difficile de garder une trace des mises à jour de sécurité pour les ports / packages, mais s'il est suffisamment critique pour être sur notre infrastructure, il est suffisamment important pour garder une trace similaire à BASE.

  • Obtenez sur la liste de diffusion pour l'application spécifique (il est de notre responsabilité de garder un œil sur les modifications en amont, indépendamment du projet OpenBSD.)

  • Obtenez sur les listes de distribution de sites de sécurité comme CERT qui publie les résultats des vulnérabilités sur les applications, etc.

Les procédures de mise à niveau

Évidemment, créez et testez votre procédure d'installation sur du matériel (ou VM) distinct avant de le faire sur vos machines de production. Heureusement pour nous, nous avons des hôtes redondants pour de nombreuses choses et pouvons donc nous déployer avec un temps d'arrêt minimal des services. Parce qu'OpenBSD prend en charge une large gamme de matériel, nous pouvons déployer des équipements de qualité serveur pour nos machines principales et des ordinateurs de bureau bas de gamme comme hôtes redondants (ou nous construisons simplement une boîte temporaire à remplir pour la machine principale pendant le cycle de mise à jour.)

Nos procédures de mise à jour dépendent fortement de l'utilisation du système de ports / packages pour les logiciels non BASE. Les deux hôtes sur lesquels nous installons le logiciel à partir de la source sont difficiles à mettre à jour entre les mises à jour de version du système d'exploitation.

Même mise à jour du système d'exploitation

Pour le système d'exploitation de base, nous continuons d'avoir du succès en installant simplement les nouveaux binaires sur les anciens. De préférence, nous sauvegardons tous les fichiers de configuration / données du système d'exploitation et de l'application, formatez et réinstallez le système d'exploitation corrigé et réinstallez les packages (en conservant les données d'origine)

Dans nos hôtes OpenBSD déployés (30+) et par expérience, la sauvegarde de la configuration et des données n'est pas difficile. Pour nos pare-feu, toutes les données se trouvent dans les fichiers de configuration et de journal.

Pour les ports / packages - où les changements sont simples, nous modifions notre propre port et construisons le package à partir de cela. Avoir un port mis à jour simplifie le processus ci-dessus.

Nouvelle mise à jour du système d'exploitation

Entre les versions du système d'exploitation, nous installons tout à partir de sketch.

Je suis sûr qu'il y a suffisamment de documentation pour le processus, mais nous construisons essentiellement une machine de référence avec la même configuration que le système à "remplacer". Passez par les mêmes tests requis avant de déployer l'hôte.

Nous sauvegardons la configuration à partir de l'hôte de référence et installons OpenBSD sur l'hôte de production, en restaurant la configuration "vérifiée" sur celui-ci (en exécutant à nouveau les mêmes tests de validation par la suite.)


Merci! C'est la direction dans laquelle je me dirige. Suivez les listes, utilisez des hôtes redondants.
Bubnoff

3

Pour OpenBSD, au moins:

  • les packages sont le produit final du système de ports; il devrait y avoir peu, voire aucun besoin de courir avec les ports.
  • -release et -stable sont (principalement) figés dans le temps, avec quelques mises à jour de temps en temps.
  • -l'actualité est régulièrement mise à jour. Si vous avez vraiment besoin de packages à jour, c'est la voie à suivre.
  • rester cohérent: -release / -stable systems coller avec -release / -stable packages ...- current systems run -current packages

FAQ 15, tout sur les ports et les packages


Oui, il semble que les développeurs / mainteneurs d'OpenBSD encouragent l'utilisation de packages sur les ports car les ports produisent le package avant l'installation. Mais l'arborescence des ports a un script d'audit (./out_of_date) ... quel est l'analogue des packages? Un portaudit pour OpenBSD ... ou suivez-vous simplement la liste de diffusion et mettez-vous à jour le ou les packages manuellement?
Bubnoff

Personnellement, avec -current c'est "pkg_add -u -Dupdate, updatedepends" ~ mensuellement pour moi. J'admets que je n'ai jamais utilisé à fond les ports comme ça; c'est généralement juste des cvs; faites une mise à jour propre pour moi si jamais je devais le faire. J'avais l'impression que ces autres scripts sont destinés aux porteurs, mais encore une fois, j'ai rarement utilisé le système de ports. Quant à l'audit, tout est fait par l'équipe des ports et bien sûr par toute autre personne qui contribue.
lonerman

@Bubnoff Si vous mettez à jour vers les dernières versions sur -stable, vous aurez tous les correctifs de sécurité publiés pour cette version. (Contrairement à -current qui inclut également des mises à jour non liées à la sécurité).
WhyNotHugo

@Hugo - merci! C'est un bon point. Je vais devoir l'écrire dans ma documentation de construction de serveur.
Bubnoff

2

S'il n'y a pas de problème de sécurité ou de bogue empêchant la fonctionnalité, laissez-le tranquille. Vérifiez les mises à jour peut-être tous les 3 à 6 mois afin de ne pas prendre trop de retard, mais sinon laissez les choses tranquilles.

Si ce n'est pas cassé, ne le réparez pas.


4
3 à 6 mois? Qu'en est-il d'Apache / lighttp ou de tout autre CMS d'applications frontales, etc.? Ne vous en faites pas? Sinon ... je vois votre point.
Bubnoff

@Bubnoff OpenBSD est livré avec un httpd personnalisé, dérivé d'Apache 1.x. La plupart des mises à jour fournies par Apache ne s'appliquent même pas.
Benoit

Je comprends que. Mais OpenBSD fournit des mises à jour de la version actuelle qui se rendra ensuite stable. Et cela laisse toujours les packages eux-mêmes ... Les applications qui utilisent Apache nécessiteraient éventuellement des mises à jour. Ou est-ce que vous mettez à jour le tout tous les six mois?
Bubnoff

Telle est mon approche. J'installe rarement quoi que ce soit hors des ports sur mes systèmes de production, donc tout ce dont j'ai vraiment besoin est l'installation de base et les packages. Je suis l'errata ( openbsd.org/errata.html ) et la liste de diffusion appropriée pour tous les packages que j'ai installés. Si j'ai installé autre chose sur le dessus, comme un système CMS, je le surveille et le gère séparément. Si j'ai besoin de corriger quelque chose de critique, je crée mon correctif sur un système de test, puis je le recopie.

1

Je préfère utiliser portupgradepour mettre à niveau les ports, et ce uniquement lorsque cela est absolument nécessaire , par exemple lorsqu'une vulnérabilité est détectée dans le port ou qu'une nouvelle fonctionnalité est requise.

Quant à la mise à niveau du système, je reconstruis généralement à partir de sources avec make buildworld. Je n'ai jamais eu de problème avec cette approche.


1
Beaucoup semblent préférer le portupgrade au portmanager. Le portupgrade est-il le plus mature des deux? Il semble que portmanager n'ait pas encore atteint 1.0.
Bubnoff

1
Oui, le portupgrade existe depuis très longtemps et semble avoir le développement et le support les plus actifs. Je sais qu'il existe d'autres outils de gestion de port, mais le portupgrade est celui qui est mentionné le plus régulièrement sur les listes. Il y a une discussion entre les deux depuis 2004 - lists.freebsd.org/pipermail/freebsd-questions/2004-December/… - que j'ai trouvée, mais je ne suis pas sûr de son actualité.
DF

J'utilise cette même approche et c'est principalement dû à l'utilisation de FreeBSD depuis les jours 4.x où buildworld et portupgrade étaient les meilleures / seules options. Ils fonctionnent toujours très bien aujourd'hui si vous avez le temps de les exécuter et le temps d'apprendre le processus. De plus, je construis toujours avec des -Osoptimisations, un système plus petit / plus rapide.
Chris S
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.