Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

Heliox · Le 02/09/2012, à 20:18

Bonjour, bonsoir,

C'est pas un scoop, maintenir son système à jour est la deuxième chose à faire pour limiter les problèmes de sécurité (la première est bien évidemment un mot de passe sûr).

Sur nos systèmes GNU/Linux, le processus de mise à jour donne à l'utilisateur un rôle clé : seulement après qu'il ait été averti par une notification, qu'il ait saisi le mot de passe du système, le processus de mise à jour peut se faire (téléchargement et installation des correctifs).
Mais, c'est aussi le gros problème, cette pratique repose obligatoirement sur l'interaction avec l'utilisateur, s'il n'est pas averti ou ne donne pas son feu vert, les mises à jour resteront en attente.

Je ne sais pas si c'est courant, mais j'observe beaucoup de systèmes (non exclusivement GNU/Linux) non mis à jour soit parce que l'utilisateur a un désintérêt pour la pratique, soit parce qu'il n'est pas averti de l'existance de nouvelles mises à jour.
Pour le désintérêt, les raisons sont souvent (d'après ce que j'observe) une procédure dont l'utilité n'est pas connu (j'ai entendu « quelle utilité de retélécharger des logiciels que l'on a déjà d'installé ») et une procédure jugée trop fastidieuse (cliquer sur l'icône de notification, attendre l'initialisation du programme de mise à jour, saisir le mot de passe).
Pour l'absence d'avertissement, j'observe cela selon les certaines distributions distributions : Ubuntu/Kubuntu nont aucun problème, Fedora Gnome non plus, mais Fedora KDE n'a aucun avertisseur de mise à jour, Debian KDE et Debian Xfce non plus (ou alors je les ai manqué !).

La solution pour pallier ces deux problèmes serait d'ajouter le processus des mises à jour à la liste des tâches effectuées automatiquement par le système sans l'intervention de l'utilisateur.
Cette solution n'a qu'un inconvéniant assez limité : dans le cas de l'administration d'un serveur, une mise à jour mal gérée peut modifier certains fichiers de configuration et affecter le bon fonctionnement du serveur.
Or dans le cas d'un ordinateur de bureau "grand public" ce cas de figure est peu probable car d'une part la distribution a une gestion des logiciels stable (on exclu ArchLinux, Debian SID/Testing) et d'autre part car redémarrer l'ordinateur n'est pas aussi critique que pour un serveur.

Donc rien ne semble s'opposer à cette pratique pour un ordinateur "grand public".

Voilà mes questions :
Pourquoi n'est-ce pas la politique par défaut des distributions "grand public" comme Ubuntu ?
Y'a-t-il d'autres raisons que j'ai omises d'être contre les mises à jour automatiques ?

Merci pour vos réponses !

Dernière modification par Heliox (Le 05/09/2012, à 13:17)

Sylvain_07 · Le 02/09/2012, à 23:06

Bonsoir,
Je parle pour moi :
personnellement ça ne me dérange pas de choisir d'installer les mise à jours ,
je suis me plutôt pour se système

1) ça te permet de voir ce qui est mis à jours et de suivre ton système.
2) peut être qu'au moment ou il va télécharger et installé la mise à jours ce n'est pas le moment le plus opportun pour toi : perte de bande passante utilisée pour télécharger les MAJ, besoin de redémarrage, arrêt d'un programme ou d'un service pour installé la mise à jours. donc je préféré choisir le moment ou j’installe les MAJ.
3) Parce que pour une raison X ou Y tu n' a peut être pas envi que tel ou tel paquet soit migrés vers une version plus récente : donc tu peut choisir.

A l'époque ou j'étais sous Windows j'avais coché me demandé avant de télécharger et d'installé les mise à jours.
là c'est comme si c'était coché automatiquement et perso ça me va bien, le contraire me déplairait.

ou alors s il faudrait avoir le choix automatique ou demandé.

Blakesnake · Le 02/09/2012, à 23:20

Je dirais qu'il suffirait de demander à l'installation si l'utilisateur veut un système mis à jour automatiquement ou non.

Pour ma part, comme Sylvain_07, je préfère être prévenu avant, histoire de savoir ce qui se passe sur ma machine. Mais pour les non-powers users comme ma grand-mère qui ne sait même pas ce qu'est un dépôt, il est certain qu'une mise en mode full-automatique des MAJ est la bienvenue.

J'ai tourné un temps sous Debian KDE, il me semble qu'il y avait bien les notifications.

kleim · Le 03/09/2012, à 10:48

Sylvain_07 a écrit :

2) peut être qu'au moment ou il va télécharger et installé la mise à jours ce n'est pas le moment le plus opportun pour toi : perte de bande passante utilisée pour télécharger les MAJ, besoin de redémarrage, arrêt d'un programme ou d'un service pour installé la mise à jours. donc je préféré choisir le moment ou j’installe les MAJ.

C'est vrai que ça fait tellement plaisir une hausse du ping puis un shutdown quand tu fais un FPS en ligne

Heliox · Le 04/09/2012, à 17:27

Bonjour,

Vous pouvez utiliser cron-apt pour choisir à quelle heure rechercher et lancer le programme de mise à jour !
Par exemple pendant l'heure du repas… (ou de la vaisselle ! )

Petit guide :

Note 1 : Ce n'est rien de compliqué, il n'y a qu'à lancer des commandes, faire des copier-coller et utiliser 2 neurones.

Note 2 : Les lignes commençant par $ sont à exécuter ne tant qu'utilisateur normal. Les lignes commençant par # sont à exécuter en tant que root.
Mais suivez les instructions et il n'y aura aucun problème !

Commencer par ouvrir un terminal et se connecter en root :
```
$ sudo -s
```
Installer cron-apt :
```
# aptitude install cron-apt
```
Éditer le fichier config (/etc/cron-apt/config) :
```
# nano /etc/cron-apt/config
```
Y ajouter les lignes suivantes :
```
APTCOMMAND=/usr/bin/aptitude
OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/sources.list"
RUNSLEEP=10
TEMP="/tmp/cron-apt_templog"
```
(enregistrer et quitter, dans nano il faut faire "ctrl + x" puis "o" puis "entrée")

Note pour les utilisateurs de Debian qui ont le dépôt "Debian Multimedia" d'activé : Les paquets téléchargés depuis ce dépôt ne sont pas authentifiés. Par conséquent Aptitude ne téléchargera pas les nouveaux paquets de ce dépôt. Pour modifier ce comportement et faire en sorte qu'Aptitude intègre aussi ces paquets dans les mises à jour, il faut, dans l'extrait ci-dessus, remplacer la ligne qui commence par OPTIONS="…" par la ligne ci-dessous:
```
OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/sources.list -o APT::Get::AllowUnauthenticated=true"
```
Éditer le fichier 3-download (/etc/cron-apt/action.d/3-download) :
D'abord, on fait une copie du fichier par défaut (au cas où) :
```
# mv /etc/cron-apt/action.d/3-download /etc/cron-apt/action.d/3-download.copie
```
Ensuite on édite le fichier en question :
```
# nano /etc/cron-apt/action.d/3-download
```
Y ajouter le contenu suivant :
```
full-upgrade -y -o APT::Get::Show-Upgraded=true
autoclean -y
clean
```
Enregistrer et quitter
Pour info, la première ligne fait une mise à jour totale et les deux dernières font le ménage après.

Éditer le fichier cron-apt :

# nano /etc/cron.d/cron-apt

Par défaut il contient ceci :

#
# Regular cron jobs for the cron-apt package
#
# Every night at 4 o'clock.
0 4     * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 *   * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 * * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

C'est à dire qu'il fera les mises à jour tous les jours à 4 heures du matin (et si l'ordinateur n'est pas démarré, il les fera au démarrage suivant)

Pour changer cela, il faut regarder la ligne-ci :

0 4     * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt

Le premier chiffre correspond aux minutes et le deuxième à l'heure de lancement de la commande.

Si on veut que le processus de mise à jour se fasse à 19h30, on modifiera cette ligne ainsi :

30 19     * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt

Enregistrer et quitter.

Voilà !
Vous pouvez fermer le terminal, les changements sont pris en compte dans les instants qui suivent.
Désormais, les mises à jour (s'il y en a) se feront tous les jours, à l'heure que vous avez choisie !

Pour les curieux qui veulent consulter les logs :

less /var/log/cron-apt/log

et

less /var/log/aptitude

("flèche du haut" et "flèche du bas" pour naviguer, "q" pour quitter)

Pour les aventuriers qui veulent explorer les options disponibles de cron-apt, voici une copie du contenu du fichier de configuration de cron-apt :

# Configuration for cron-apt.
# The cron config is located in /etc/cron.d/cron-apt
# This shows the defaults.

# The command used to execute all actions.  By default, apt-get is used.
# Change this to /usr/bin/aptitude to use aptitude instead, which will
# resolve changed Recommends (and Suggests as well, if aptitude is so
# configured). You can also set other utilities (especially useful in the
# config.d directory) so set some completely different tool.
# OBSERVE that this tool is indended for apt-get and tools like aptitude do not
# have full support for noninteractive upgrades. You may have to tune options
# to not create infinit logfiles for example.
# APTCOMMAND=/usr/bin/apt-get
# APTCOMMAND=/usr/bin/aptitude
# APTCOMMAND=/usr/bin/apt-file

# If FILTERCTRLM is "true", then any line containing ^M in the apt-get
# output will be filtered from log/mail/console output.  This is useful
# with aptitude, which does not currently support -qq (very quiet).
# This feature is considered exprimental and will not work with
# for example MAILON=upgrade.
# FILTERCTRLM="false"

# A path is needed for this to work. This is the default PATH.
# export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

# The random sleep time in seconds. This is used to prevent clients from
# accessing the APT sources all at the same time and overwhelming them.
# Default is 3600 seconds which means one hour.
# RUNSLEEP=3600

# The directory where the actions is stored.
# ACTIONDIR="/etc/cron-apt/action.d"

# The directory where configuration per action is stored. The message file
# must have the same name as the action file.
# ACTIONCONFDIR="/etc/cron-apt/config.d"

# The directory where messages that will be prepended to the email that is
# sent (per action) is stored. The message file must have the same name as
# the action file.
# MAILMSGDIR="/etc/cron-apt/mailmsg.d"

# The directory where messages that will be prepended to text that is
# sent (per action) to syslog. The message file must have the same name as
# the action file.
# SYSLOGMSGDIR="/etc/cron-apt/syslogmsg.d"

# The directory where messages that will be prepended to the error message
# (per action) is stored. The message file must have the same name as
# the action file.
# ERRORMSGDIR="/etc/cron-apt/errormsg.d"

# The directory where messages that will be prepended to the log (debug)
# message (per action) is stored. The message file must have the same name as
# the action file.
# LOGMSGDIR="/etc/cron-apt/logmsg.d"
# The directory where messages that will be prepended to the mail message
# (per MAILON type) is stored. The message file must have the same name as
# the $MAILON directive.
# MAILONMSGSDIR="/etc/cron-apt/mailonmsgs"

# The directory where messages that will be prepended to the syslog message
# (per SYSLOGON type) is stored. The message file must have the same name as
# the $SYSLOGON directive.
# SYSLOGONMSGSDIR="/etc/cron-apt/syslogonmsgs"

# Value: ""       (warn if dotlockfile not installed)
#        "nowarn" (don't give warning if dotlockfile not installed)
# NOLOCKWARN=""

# The file that contains error messages.
# ERROR="/var/log/cron-apt/error"

# The file that contains current run information
# when still running the script.
# TEMP="/var/log/cron-apt/temp"

# The logfile (for debugging). Use syslog for normal logging.
# LOG="/var/log/cron-apt/log"

# The mail file.
# MAIL="/var/log/cron-apt/mail"

# The email address to send mail to.
# MAILTO="root"

# When to send email about the cron-apt results.
# Value: error   (send mail on error runs)
#        upgrade (when packages is upgraded)
#        changes (mail when change in output from an action)
#        output  (send mail when output is generated)
#        always  (always send mail)
#                (else never send mail)
# MAILON="error"

# Value: error   (syslog on error runs)
#        upgrade (when packages is upgraded)
#        changes (syslog when change in output from an action)
#        output  (syslog when output is generated)
#        always  (always syslog)
#                (else never syslog)
# SYSLOGON="upgrade"

# Value: error   (exit on error only)
#                (else never exit)
# EXITON="error"

# Value: verbose (log everything)
#        always  (always log)
#        upgrade (when packages is upgraded)
#        changes (log when change in output from an action)
#        output  (log when output is generated)
#        error   (log error runs only)
#                (else log nothing)
# DEBUG="output"

# What to do with the diff when *ON=changes.
# Value: prepend (prepend to the output)
#        append  (append to the output)
#        only    (only show the diff, not the output itself)
#                (else do nothing)
# DIFFONCHANGES=prepend

# General apt options that will be passed to all APTCOMMAND calls.
# Use "-o quiet" instead of "-q" for aptitude compatibility.
#  OPTIONS="-o quiet=1"
# You can for example add an alternative sources.list file here.
#  OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"
# If you want to allow unauthenticated and untrusted packages add the
# following to your options directive.
# This will only work with aptitude >= 0.3.5
# The --assume-yes option will answer yes to almost all questions. This
# is not very safe, and can fill up your /tmp file system (#316606) due
# to an aptitude bug (#332885) which shows if --assume-yes is used and
# untrusted packages would be installed. This aptitude bug is fixed in
# aptitude 0.3.4.
#  OPTIONS="-o quiet=1 -o APT::Get::AllowUnauthenticated=true -o aptitude::Cmdline::ignore-trust-violations=yes"

# Do not run the command, if there is an error in the previous run (default).
# Value: error   (do not run if there is an error on last run)
#                (else always run, remove previous error file and run)
# DONTRUN=""

# If this file exist cron-apt will silently exit.
# REFRAINFILE=/etc/cron-apt/refrain

# If this is non-empty, it will be used as the host name in subjects of
# generated e-mail messages. If this is empty, the output of uname -n
# will be used.
# HOSTNAME=""

# Ignore lines matching this regexp to determine whether changes occurred
# for MAILON="changes". If empty no lines will be ignored.
# Suggested value for aptitude:
#  DIFFIGNORE="^\(Get:[[:digit:]]\+\|Hit\|Ign\|Del\|Fetched\|Freed\|Reading\)[[:space:]]"

# Suggested value for apt-get:
#  DIFFIGNORE="^\(Get:[[:digit:]]\+\|Hit\|Ign)[[:space:]]"
# Default:
#  DIFFIGNORE=""

Et enfin les sources (moyennement fiables ) :
http://jeyg.info/garder-sa-debian-a-jou … -fatiguer/
http://blog.nozav.org/post/2007/01/12/6 … ous-debian
http://blog.pastoutafait.org/billets/Mi … c-Cron-APT

Dernière modification par Heliox (Le 05/09/2012, à 14:19)

LegSim · Le 04/09/2012, à 22:20

Salut,

Il me semble avoir déjà eu ce problème il y a fort longtemps (du temps où j'étais encore sous Debian ) !
C'était à cause du PATH qui n'était pas renseigné correctement lors de l'appel par cron. Tu peux le renseigner directement dans ta crontab (/etc/cron.d/cron-apt ici) en ajoutant une ligne (en en-tête) du genre PATH=/usr/bin:...

Je ne sais pas si c'est ça le problème ici (c'est vrai que sans log ) mais autant proposer

Dernière modification par LegSim (Le 04/09/2012, à 22:21)

Heliox · Le 05/09/2012, à 13:32

@LegSim :

Merci de la réponse ! J'ai essayé en renseignant de PATH, mais sans plus de succès…
J'ai continué mes recherches jusqu'à tomber sur un site (j'ai perdu l'adresse) qui donnait un lien vers le contenu "par défaut" du fichier de configuration de cron-apt (or ce même fichier "par défaut" sur Debian et Kubuntu qui ne contient que deux lignes d'information commentées…). Avec ce fichier j'ai pu voir toutes les options disponibles, et le problème venait de l'option RUNSLEEP=3600 par défaut qui laissait s'écouler une heure avant de continuer l'exécution de cron-apt (à se demander à quoi ça sert de paramétrer une heure précise si c'est pour démarrer une heure après… ).
Quoiqu'il en soit, j'ai modifié cette option pour ramener le délai à 10 secondes, et depuis ça marche.
J'ai eu quelques autres problèmes (le fichier 5-install ne sert à rien, dossier temporaire) que j'ai pu résoudre facilement.

Maintenant tout marche parfaitement, tant sur Debian que sur Kubuntu.
Mais c'est à se demander pourquoi est-ce que Debian efface ne laisse pas le contenu du fichier de configuration par défaut (même commenté).

Je vais éditer mon précédent message pour en faire un tuto viable.
Edit : fait !

Merci !

Au fait, tu utilises quoi si tu n'utilises plus Debian ?
Et pour toute ton infrastructure LegTux, tu utilises quelle(s) distribution(s) ?
Ah ! Et comme tu sembles être familier des serveurs, les contre-indications par rapport à la mise à jour automatique sont vraiment justifiées ou ça représente un risque minime ?
Peut-il y avoir des problèmes dans le cas d'une utilisation desktop ?

Dernière modification par Heliox (Le 05/09/2012, à 14:20)

LegSim · Le 05/09/2012, à 23:00

Pour une utilisation "de tous les jours", je me suis tourné vers ArchLinux. Paradoxalement, je dirais que c'est par flemme (oui, oui, un peu étrange, je le concède ), puisque maintenant que mes systèmes sont installés, je n'ai plus à me soucier de choses comme des mises à niveau.
Pour mes ordinateurs persos je reste en mise à jour manuelle (j'aime bien voir ce qui se passe), mais pour l'ordinateur de mes parents, j'utilise cron pour mettre à jour automatiquement le système (toutes les heures même). Il y a eu une seule fois un problème, l'ordi a été éteint en pleine mise à jour de je ne sais plus quel paquet indispensable... Je vous laisse imaginer la panique au démarrage suivant !
Donc vraiment, oui, pour une utilisation desktop, il faudrait proposer (pas imposer, hein ) les mises à jour automatiques.

Pour LegTux, je suis toujours sur du Debian (6.0 là), ça tourne très bien, j'ai pas à me plaindre ! Évidemment, pas de mises à jour automatiques, faut pas déconner : les mises à jour de PHP, de MySQL, etc. redémarrent ces daemons (à des moments pas forcément intéressants) causant donc de l'indisponibilité, et puis il serait malvenu qu'une mise à jour PHP vienne casser la compatibilité avec trop de scripts, vaut mieux lire les grosses lignes des changelogs avant !

Dernière modification par LegSim (Le 05/09/2012, à 23:01)

sorrodje · Le 06/09/2012, à 09:13

LegSim a écrit :

Pour LegTux, je suis toujours sur du Debian (6.0 là), ça tourne très bien, j'ai pas à me plaindre ! Évidemment, pas de mises à jour automatiques, faut pas déconner : les mises à jour de PHP, de MySQL, etc. redémarrent ces daemons (à des moments pas forcément intéressants) causant donc de l'indisponibilité, et puis il serait malvenu qu'une mise à jour PHP vienne casser la compatibilité avec trop de scripts, vaut mieux lire les grosses lignes des changelogs avant !

C'est clair !

J'ai par contre opté sur mon serveur 12.04 pour l'automatisation des MAJ de sécurité .. j'ai eu beau cogiter sur la pertinence ou de cette option mais ça me parait logique de ne pas tergiverser avec ça et donc d'automatiser.

Si jamais j'ai un souci un jour, je reviendrai probablement sur ce choix

Heliox · Le 06/09/2012, à 14:06

@LegSim : OK, merci !

sorrodje a écrit :

C'est clair !
J'ai par contre opté sur mon serveur 12.04 pour l'automatisation des MAJ de sécurité .. j'ai eu beau cogiter sur la pertinence ou de cette option mais ça me parait logique de ne pas tergiverser avec ça et donc d'automatiser.
Si jamais j'ai un souci un jour, je reviendrai probablement sur ce choix

Et si jamais un programme nouvellement mis-à-jour nécéssite un redémarrage du système, comment fais-tu pour le savoir ?

BrunoGey · Le 06/09/2012, à 14:37

Sylvain_07 a écrit :

Bonsoir,
Je parle pour moi :
personnellement ça ne me dérange pas de choisir d'installer les mise à jours ,
je suis me plutôt pour se système
1) ça te permet de voir ce qui est mis à jours et de suivre ton système.
2) peut être qu'au moment ou il va télécharger et installé la mise à jours ce n'est pas le moment le plus opportun pour toi : perte de bande passante utilisée pour télécharger les MAJ, besoin de redémarrage, arrêt d'un programme ou d'un service pour installé la mise à jours. donc je préféré choisir le moment ou j’installe les MAJ.
3) Parce que pour une raison X ou Y tu n' a peut être pas envi que tel ou tel paquet soit migrés vers une version plus récente : donc tu peut choisir.

A l'époque ou j'étais sous Windows j'avais coché me demandé avant de télécharger et d'installé les mise à jours.
là c'est comme si c'était coché automatiquement et perso ça me va bien, le contraire me déplairait.
ou alors s il faudrait avoir le choix automatique ou demandé.

Bonjour,

+1 pour cet argumentaire.

Je rajoute même, que dans l'utilitaire de MAJ, j'ai coché l'option pour ne pas inclure les mises à niveau

cdt

bruno

sorrodje · Le 06/09/2012, à 17:49

Heliox a écrit :

@LegSim : OK, merci !
sorrodje a écrit :
C'est clair !
J'ai par contre opté sur mon serveur 12.04 pour l'automatisation des MAJ de sécurité .. j'ai eu beau cogiter sur la pertinence ou de cette option mais ça me parait logique de ne pas tergiverser avec ça et donc d'automatiser.
Si jamais j'ai un souci un jour, je reviendrai probablement sur ce choix
Et si jamais un programme nouvellement mis-à-jour nécéssite un redémarrage du système, comment fais-tu pour le savoir ?

Jamais vu pour le moment. La nécessité de redémarrage s' affiche dans les infos quand je me connecte (via ssh en l'occurence). je n'ai plus qu'à effectuer un redémarrage dans des horaires ou l'indispo est peu impactante.

De mémoire le seul redémarrage que je me sois vu demander concerne les MAJ (montées de version) du noyau . Sinon ça peut être un stop/start de certains services mais l'indispo dans ce cas est vraiment brève

Donc pour le moment RAS.

Dernière modification par sorrodje (Le 06/09/2012, à 17:50)

metalux · Le 20/09/2012, à 23:15

Bonsoir,
Pour ma part, j'utilise unattended-upgrades (voir ma signature) pour faire mes mises à jours depuis un an maintenant et aucun problème rencontré à part une mise à jour partielle qui du coup ne s'effectuait pas pour laquelle je suis passé par synaptic. J'utilise également plusieurs P.P.A., peut-être est-ce la raison de cette mise à jour partielle.

Pourquoi n'est-ce pas la politique par défaut des distributions "grand public" comme Ubuntu ?

C'est là tout l'intérêt de mon script, les personnes à qui j'ai fais découvrir Ubuntu n'en n'ont que faire des mises à jour, elles souhaitent que ce processus soit le plus transparent possible. Je suis relativement d'accord sur le fait qu'il faudrait proposer une case à cocher pour activer cette fonctionnalité sur une distribution "grand public". Quant à savoir les paquets installés automatiquement, il y a toujours les fichiers log (/var/log/unattended-upgrades)

chat-toon · Le 22/09/2012, à 16:18

J'aime que le systeme linux me demande si je souhaite mettre a jour et installer les mise a jour . rien a voir avec Seven qui charge parfois deux fois les memle trucs pour rien .
Tant que cela fonctionne c'est bien .
En tous cas rien a voir avec ces mise a jours type mandriva 2009 en 2010 par exemple .

gnales · Le 22/09/2012, à 18:49

Perso je trouve que c'est mieux d'avoir le choix, pas comme si il suffisait d'appuyer sur un bouton pour tout lancé. ^^

metalux · Le 22/09/2012, à 19:41

gnales a écrit :

Perso je trouve que c'est mieux d'avoir le choix.

Or actuellement il n'y a pas le choix de faire ses mises à jours automatiquement et l'argumentaire d'Heliox est pertinent pour une distribution grand public. Je détourne un peu ton propos qui concernait évidement le choix des mises à jours, mais il ne serait pas aberrant d'avoir ce comportement par défaut pour le grand public tout en permettant aux utilisateurs plus avancés d'avoir le comportement actuel.

gnales · Le 22/09/2012, à 19:59

Après même si ubuntu est sensé être une distribution grand public quasiment tout ceux qui sont dessus y sont par choix et donc il sont près à supporter ça je crois. ^^

metalux · Le 24/09/2012, à 00:01

Je suis actuellement sur un Live-cd de Fedora étant obligé de changer de distribution dû à une surchauffe de mon portable avec ubuntu 12.04(voir ma signature au passage si quelqu'un puisse m'aider) et je viens de découvrir que cette distribution propose ce choix, alors pourquoi pas Ubuntu? Et pourtant elle touche un public un peu moins large qu'Ubuntu si je ne dis pas de bêtises.

fabr · Le 30/09/2012, à 14:52

Bonjour à tous,
Avant d'utiliser Kubuntu j'ai passé près de 10 ans sous Mandriva.
Il été donné la possibilité aux simples utilisateurs de mettre à jour en saisissant leur mot de passe sans pour autant avoir accès à l'installation des paquetages.
Je trouve que ce principe manque sur unbuntu ou alors existe-t-il, auquel cas j'aimerai bien savoir comment faire.

metalux · Le 30/09/2012, à 16:40

Bonjour fabr,
sudoers doit te permettre de mettre ça en place. Par exemple en ajoutant user ALL=/usr/bin/apt-get (user à remplacer par le nom d'utilisateur auquel tu veux donner accès à apt), l'user en question pourra installer des paquets.

Bob49 · Le 30/09/2012, à 16:42

Bonjour
Perso, je préfère être averti et mettre à jour quand ça m'arrange.
Une mise à jour n'est pas à une demi-journée ou une journée près !...donc ça peu attendre aussi.
Je suis à 100% contre les mises à jour qui s'installent toutes seules, sans avertissement. Et pour le moment avec mes systèmes Linux, dont ma version d'Ubuntu, c'est moi qui donne l'aurorisation.

Comme ce n'est pas le nombre de mises à jour (sauf après vacances ), s'il y en à pas pour Firefox, je surfe pendant que les mises à jour se font.
Pour les mises à jour conséquentes et bien je laisse mon pc, le temps qu'elles se fassent. Je vais pas en mourir ....Soit je m'attaque à autre chose chez moi, soit je lance mon pc portable.

Dernière modification par Bob49 (Le 30/09/2012, à 16:46)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/09/2012, à 20:18

Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#2 Le 02/09/2012, à 23:06

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#3 Le 02/09/2012, à 23:20

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#4 Le 03/09/2012, à 10:48

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#5 Le 04/09/2012, à 17:27

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#6 Le 04/09/2012, à 22:20

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#7 Le 05/09/2012, à 13:32

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#8 Le 05/09/2012, à 23:00

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#9 Le 06/09/2012, à 09:13

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#10 Le 06/09/2012, à 14:06

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#11 Le 06/09/2012, à 14:37

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#12 Le 06/09/2012, à 17:49

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#13 Le 20/09/2012, à 23:15

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#14 Le 22/09/2012, à 16:18

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#15 Le 22/09/2012, à 18:49

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#16 Le 22/09/2012, à 19:41

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#17 Le 22/09/2012, à 19:59

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#18 Le 24/09/2012, à 00:01

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#19 Le 30/09/2012, à 14:52

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#20 Le 30/09/2012, à 16:40

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

#21 Le 30/09/2012, à 16:42

Re : Mise à jour automatique : Vous en pensez quoi ? Vous faites comment ?

Pied de page des forums