Question SysAdmin & Developer: Responsibilities [fermé]


En ce qui concerne un serveur Web de production, quelle est la meilleure pratique en matière de responsabilités pour l'administrateur système et le développeur? Plus précisément, je pense à la mise à jour / l’installation du logiciel. (À mon sens, le développeur ne devrait pas avoir un accès root sur le serveur de production.)

Ainsi, un serveur Web de production exécute Wordpress et doit être mis à jour à la dernière version. Qui est responsable de le maintenir à jour?

Que se passe-t-il si les développeurs ont des plugins personnalisés piratés ou des fichiers core personnalisés sur l'application (dans cet exemple, WP)?


26
2017-09-06 21:01


origine


Où se trouvent les documents de développement sur les plug-ins et où sont les sauvegardes des fichiers principaux et quand a eu lieu la dernière fois que les sauvegardes et la documentation ont été testées dans votre environnement de développement? - ForgeMan
Qu'en est-il des privilèges basés sur les rôles? donnez-leur un accès sécurisé et vérifié à ce qu’ils doivent faire sans visser votre serveur. - allruiz


Réponses:


J'ai constaté que dans la plupart des cas, si VOUS êtes le responsable du serveur physique, il est préférable de ne PAS donner aux développeurs l'accès root.

C'est un peu un débat de "guerre sainte" car je suis sûr que vous trouverez des développeurs qui ne sont pas d'accord. J'ai personnellement été des deux côtés de ce débat.

Mon raisonnement PRINCIPAL pour ne pas donner aux développeurs devs (même à 100% de ceux qui ont confiance en eux) un accès root est dû au fait qu’il existe le plus souvent un paquet nécessaire pour que XYZ fonctionne correctement. Ils vont de l'avant et l'installent ... ou reconfigurent quelque chose qui est déjà en place pour que cela fonctionne ... ou ... eh bien ... vous voyez l'idée.

Des mois ont passé ... le serveur doit être réinstallé ou recréé ... et tout à coup, personne ne sait pourquoi. "Cela fonctionne sur l'ancien serveur mais pas sur le nouveau."

La réponse est bien sûr que la documentation que vous consultez n'inclut pas tous ces petits paquets et modifications que les développeurs ont faits pour que le système fonctionne la première fois.

Cela peut être pénible pour les deux côtés ... mais si l'administrateur système est responsable du serveur, des packages et de la documentation ... et que le développeur est responsable du développement et des logiciels ... je pense que vous " Je trouverai que ça valait le coup à la fin.

Si le développeur a besoin d'un plugin, d'un module, d'une configuration personnalisés, d'un tweak ... pas de problème ... faites-le pour eux ... mais DOCUMENT IT afin que vous puissiez le reproduire la prochaine fois.


21
2017-09-06 21:21



Alors, qu'en est-il d'une situation telle que celle décrite ci-dessus, où l'accès root n'est pas nécessaire pour mettre à jour une application (telle que Wordpress). Qui devrait être responsable de le tenir à jour? - Josh Brower
Dans ce cas particulier, il s’agit essentiellement de politique (décision de gestion). Dans mon organisation, c'est l'administrateur système qui est chargé de maintenir les serveurs corrigés et à jour, et dans ce cas, de maintenir Wordpress à jour. Le travail de l'administrateur système consiste à sécuriser le serveur. Cela me semble (surtout de nos jours) garder Wordpress à jour en fait partie. - KPWINC
Si vous aviez un serveur géré dans une société d’hébergement, il serait peu probable qu’il couvre Wordpress. En règle générale, quiconque a installé le logiciel en est responsable. Les administrateurs installeraient le système d'exploitation, le serveur Web, etc. Les développeurs installeraient Wordpress. - ollybee


règle d'or: Ne laissez pas les non-administrateurs toucher ce que vous ne voulez pas briser et pour lequel vous serez tenu responsable.

Les développeurs doivent avoir accès à un environnement de test. Une fois que leur travail est prêt à être placé sur la machine de production, il doit être remis à l’administrateur système. Si les développeurs ont fait leur travail et ont bien documenté la procédure, tout ira bien. Si ce n'est pas le cas, ils ont besoin de coups de pied à l'arrière pour ne pas effectuer les tests nécessaires.


16
2017-09-07 00:08



Amen! Une façon magique de faire partir un développeur ... Demandez-lui "Cela fonctionne-t-il dans l'environnement de développement?" ou "Où est votre feuille de construction?" - ForgeMan


J'ai été dans cette bataille aussi. Ma réponse est que quiconque est responsable de la disponibilité du serveur est celui qui devrait être responsable de toutes les mises à jour, modifications, etc., etc. Nobodoy devrait avoir la possibilité d'exécuter ces types de fonctions sur le serveur. Si vous devez vous assurer que le serveur est opérationnel et si le responsable vous tient pour responsable, il vous incombe de le maintenir et de le sécuriser.

La plupart des développeurs vont vous dire qu'ils ont besoin d'un accès de niveau administrateur au serveur et la plupart d'entre eux vont être en désaccord avec moi, mais je suis celui qui doit le redémarrer à 2 heures du matin lorsqu'il le raccroche, doit le reconstruire après une mise à jour ayant échoué, le temps d'arrêt est facturé à mon service, etc., etc. Je dois répondre au CIO de tout ce qui a une incidence sur notre accord de niveau de service. Je suis donc le seul à avoir un accès de niveau administrateur au serveur, et je ' m responsable de tous les composants, mises à jour, modifications, etc.


12
2017-09-06 23:30



Ici! ici! : - J-2 - 3 H n’est pas un moment amusant pour faire face à un changement insensé. (J'y ai vu ... visudo l'a résolu). - ForgeMan
J'aime beaucoup l'idée que "quiconque est responsable de la disponibilité du serveur est celui qui devrait être responsable de toutes les mises à jour, modifications" - cela a beaucoup de sens. - Josh Brower


Je suis 100% d'accord. Les développeurs ne sont généralement pas conscients du fonctionnement des choses syadmin. S'ils ont besoin de quoi que ce soit, ils vous le demandent, c'est tout. Vous réfléchissez à quand et comment et vous leur livrez un paquet utilisable. (Comme ils ont besoin d’envoyer des emails, VOUS êtes celui qui va configurer postfix). De plus, ils auront tendance à penser que, dans la plupart des cas, l'accès root fera fonctionner les choses s'ils ne sont pas capables de le faire avec un accès normal. Je suis d'accord avec les autres ici, ils ne seront pas avec vous à 2 heures du matin quand vous verrez un problème. J'ai eu le cas il y a quelques semaines, un développeur a voulu mettre à jour sa wordpress. Je lui ai dit RTF changelog, pour lui, c'était inutile, le processus de mise à jour se fait à travers une belle interface. La mise à jour ne fonctionnait pas, j'avais son application sauvegardée, le script de sauvegarde n'était pas lui. Sans moi, il n'aurait pas pu restaurer le site. Alors prenez soin de ces choses, nous passons du temps à mettre en place des stratégies (chrooter, sauvegarder, configuration) c'est pourquoi nous sommes ici (et nous l'aimons :)) et dev ne devrait JAMAIS interférer avec ces choses (redonner à César ce qui appartient à César )


1
2017-09-08 07:17





Il y a une tendance à brouiller la distinction entre dev et opérations. Faites vos administrateurs systèmes et vos développeurs administrateurs.

En ce sens, Wordpress pourrait tirer parti de certains travaux sur la création automatique (et par programmation) de blogs. De nombreux utilisateurs de wordpress gèrent plusieurs instances de WP / WPMU et leur mise à jour rapide est fastidieuse.

Vous pouvez trouver un aperçu agréable (et amusant) de la philosophie à l'adresse Agile Infrastructure glisse depuis Agile 2009


1
2017-09-07 09:38





Les développeurs ne devraient pas avoir la racine sur la production; tout le monde sauf les développeurs est d'accord sur ce point. Mais les développeurs peuvent en quelque sorte avoir leur gâteau et le manger aussi. Je suis un peu surpris que personne ne l'ait explicitement mentionné:

Un de mes très anciens clients PME possède un site Web avec une installation de Drupal, plusieurs sites WordPress, un forum SMF et quelques autres petites applications Web aléatoires. Je suis l'administrateur système du contrat (et, pour des raisons historiques, met également à jour / pirate WordPress et SMF en cas de besoin) et mon client dispose de son propre contrat de développeurs Drupal. L'environnement est constitué de plusieurs machines virtuelles VMware sur un fournisseur de cloud public.

Les développeurs veulent vraiment avoir un accès root et en ont besoin. Il est de leur responsabilité d’écrire les règles de réécriture de nginx pour que tous leurs trucs Drupal personnalisés fonctionnent, par exemple. Mais aucun moyen ne leur donne un accès root sur le serveur de production, et mon client est d'accord avec moi à ce sujet.

Nous avons donc compromis: ils obtiennent un accès root sur le serveur Web de test (qui est généralement identique à la production, à l'exception de son adresse IP et se trouvant sur le même cloud). Ce qui, comme la production, a etckeeper, ce qui me permet de voir les modifications qu’ils doivent apporter et les packages qu’ils ont installés. Je peux alors soit intégrer les modifications dans la production, soit leur dire ce qui ne va pas avec ce qu'ils veulent faire. Et s’ils ont vraiment foiré (ils ne l’ont pas encore, merci), je peux facilement revenir sur leurs modifications.

Ils n'ont aucun accès au serveur de base de données de production; ils n'ont même pas de noms d'utilisateur. Seulement mon client et moi.

(L’application Web elle-même, elle se déploie directement avec git, et si elle la casse, elle doit la réparer et expliquer à mon client pourquoi elle devrait rester ses développeurs. Bien que mon client m’ait envoyé un message CC de ce type pour que je puisse rire d’eux ou facepalm.)


1
2017-08-27 08:09





Racine == Administrateur système.

Utilisateurs == Développeurs, DBA ou Utilisateurs.

Root ne connaît pas de sommeil lorsqu'un serveur est en panne, root protège les utilisateurs d'eux-mêmes, root protège les données des utilisateurs du réseau, root met la santé du serveur au-dessus de tous les utilisateurs. Le cul de la racine est en ligne lorsque le serveur est hors ligne. Serveur heureux, racine heureuse!

Raisons courantes des temps d'arrêt non planifiés: utilisateurs, modifications non documentées de l'environnement et rétrocaveuses. Les serveurs font exactement ce qu'on leur dit, ils ne font pas que casser au hasard. Les pirates vous demandez, ce n'est pas si, c'est quand ... d'où la nécessité d'une "racine".

00:33 CDT savez-vous où sont vos sauvegardes et vos documents de récupération après sinistre? :-p


0
2017-09-07 05:34