update-manager en ligne de commande

temps · Le 08/03/2016, à 11:17

Bonjour,
Je cherche à modifier le paramétrage de update-manager en ligne de commande.
Si je me connecte sur un poste distend et que je lance dans un terminal

update-manager

j'obtiens

Gtk-WARNING **: cannot open display

car update-manager fonctionne en mode graphique.
Existe-t-il une solution pour que je puisse le modifier en ligne de commande ?

Cordialement

credenhill · Le 08/03/2016, à 11:21

hello
essayer

export DISPLAY=:0; update-manager

temps · Le 08/03/2016, à 11:26

Bonjour,
Merci pour la réponse.

J'obtiens :

export DISPLAY=:0; update-manager

(update-manager:2437): dconf-WARNING **: failed to commit changes to dconf: Could not connect: Connection refused

(update-manager:2437): libunity-CRITICAL **: unity-launcher.vala:154: Unable to connect to session bus: Could not connect: Connection refused
warning: could not initiate dbus

(update-manager:2437): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: Could not connect: Connection refused

temps · Le 08/03/2016, à 11:31

Je pense que la solution est plus dans la modification des fichiers qu'en voulant exporter l'écran, car cela me permettrais d'écrire un script pour automatiser l'action.

Dans /etc je pense

Cordialement

Dernière modification par temps (Le 08/03/2016, à 11:34)

carreti · Le 08/03/2016, à 12:47

Hello,

apparemment tu essayes d'obtenir une interface graphique en root ou en sudo ?
Peut être essayer de passer par kdesu pour y être autorisé ...

EDIT: désolé j'avais lu en diagonale, je n'avais pas vu qu'il s'agissait d'un poste distant.
Peut être que cela réponds à ta question : http://ubuntuforums.org/showthread.php?t=1201354

Sinon quant un programme ne dispose pas de mode texte seul (je n'utilise pas update-manager n'étant pas sur ubuntu) ou n'a pas d'alternative en ligne de commande, il faut forwarder X (et donc avoir un serveur X qui tourne en local, il en existe pour Windows ...).

Dernière modification par carreti (Le 08/03/2016, à 13:02)

temps · Le 08/03/2016, à 20:28

Bonjour,
merci pour le lien.
La problématique d'un poste distend c'est que lorsqu'on quitte, en même temps on arrête l'action.
Il est possible de détacher la tache avec l'option -d , mais comme dans le cas d'un upgrade, il faut confirmer la demande, cette option devient inutilisable.
Imaginons un débit exceptionnellement bas, qui demande plus d'un jour pour une mise à jour; il reste deux solutions :
soit cron qui lance l'action en ayant pris le soin de donner les droit à l'action pour quelle ne demande pas de mot de passe (je l'ai déjà fait sur certains postes).
soit paramétrer update-manager pour qu'il installe tout seul les mises à jour de sécurité.
J'ai choisit d'essayer de paramétrer update-manager en ligne de commande, c'est pourquoi, j'ai ouvert ce fil.
Cordialement

carreti · Le 09/03/2016, à 06:00

Hello,

en lançant une commande en nohup, on ne tue aucun process si on se déconnecte après avoir validé les éventuelles réponses demandées en mode interactif, bien sûr si c'est après des heures de récupération et d'installation qu'une intervention de l'opérateur est demandée par la commande, c'est plus problématique.

apt-get semble disposer de quelques modes permettant à un admin d'optimiser, sécuriser et/ou d'automatiser les choses : mode quiet, download only, dry run, etc ...

Une petite recherche m'a aussi remonté tasksel qui est peut-être plus adapté ? http://www.blog-des-telecoms.com/howto- … ntu-server ou d'une façon plus générale https://doc.ubuntu-fr.org/tasksel ...

Je crois que cela dépends aussi du nombre de postes distants que l'on doit gérer ... Est-il plus rentable de scripter pour automatiser, de s'appuyer sur des solutions existantes ou de le faire manuellement ?

temps · Le 09/03/2016, à 07:54

Bonjour,
Merci pour le retour de toutes ces précieuses informations.
Je teste ces jours-ci et je viens donner le retour.
J'avais déjà écris un petit script en bash lancer en C, qui automatisait les apt en distant par vague de 24 postes,
mais un manque de débit provisoire l'a rendu inutile.

Cordialement

carreti · Le 09/03/2016, à 10:53

temps a écrit :

J'avais déjà écris un petit script en bash lancer en C, qui automatisait les apt en distant par vague de 24 postes,
mais un manque de débit provisoire l'a rendu inutile.

Hello,

à oui ça commence à faire ... et ça autorise forcément d'investir un peu de temps à la manœuvre, ce qu'on peut faire chez soi n'est absolument pas pertinent sur de telles quantités. Si il y a des problèmes de débit (internet / LAN?) et que le parc est plutôt homogène il doit être possible de mirorer quelques part les packages nécessaires et de les copier sur les machines en préalable au lancement d'une mise à jour, si besoin en répartissant l'upload sur les machines pour soulager le LAN, (voir de se garder sous le coude un miroir complet accessible si besoin) puis d'installer sur les machines à partir des packages locaux. Il est en tous cas clairement impossible de tout faire manuellement.

Après, je suppose que la récupération, le filtrage/analyse des logs et la résolution des problèmes qui ne manqueront pas d'arriver représentera aussi du boulot.

Je suis pas (plus) admin (plutôt chômeur longue durée), je connais pas du tout Ubuntu (mes machines sont sous Gentoo), dommage que tu n'ais pas de réponses plus avisées que les miennes venant de quelqu'un de familier avec ce genre d'opérations. Il existe forcément des "best practices" adaptées à tes problématiques.

Dernière modification par carreti (Le 09/03/2016, à 10:55)

temps · Le 09/03/2016, à 11:39

Bonjour,
Merci pour la réponse.
J'ai retrouvé mon débit mais la curiosité pousse et je pense qu'analyser chaque événement apporte toujours quelque chose.
Concernant mon retour d'expérience depuis 2006, c'est qu'il n'y a pas de "best practices".
Un truc bon à tout est un truc bon à rien.
Je faisais de la Vidéo A la Demande avec des P2 (ancien processeur) et j'ose même pas citer mes cartes réseaux ou connectiques faites main (sans nunux, tout espoir aurait été perdu).
En fait le mieux est toujours ce que l'on a monté soi-même, car il est adapté et ne fait pas de choses inutiles. Question sécurité aussi c'est le top, car seul celui qui a monté ses postes sait comment il les a monté, et la meilleur des protections est apporté par une structure particulière et les mises à jours de sécurité régulières (jamais eu de problèmes en plus de 10 ans avec des publique curieux dont master informatiques. J'ai bien vu des traces, souvent des recherches de root (mais pas actif sous mes ubuntu donc sans danger).
Je connais plusieurs admin avec beaucoup de compétences qui n'ont pas leur entreprise ou un salaire. En fait le fun du code n'est pas lié à un sexe, à l'age ou une situation professionnelle, le meilleur des codes est toujours celui que l'on a écrit et qu'on peut modifier selon les besoins.
J'ai pas le temps de tester aujourd'hui mais je le ferai dans les jours qui viennent.
Cordialement

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/03/2016, à 11:17

update-manager en ligne de commande

#2 Le 08/03/2016, à 11:21

Re : update-manager en ligne de commande

#3 Le 08/03/2016, à 11:26

Re : update-manager en ligne de commande

#4 Le 08/03/2016, à 11:31

Re : update-manager en ligne de commande

#5 Le 08/03/2016, à 12:47

Re : update-manager en ligne de commande

#6 Le 08/03/2016, à 20:28

Re : update-manager en ligne de commande

#7 Le 09/03/2016, à 06:00

Re : update-manager en ligne de commande

#8 Le 09/03/2016, à 07:54

Re : update-manager en ligne de commande

#9 Le 09/03/2016, à 10:53

Re : update-manager en ligne de commande

#10 Le 09/03/2016, à 11:39

Re : update-manager en ligne de commande

Pied de page des forums