Ubuntu-fr

Bonjour,
Merci pour ton aide.

Oui, je sais bien le principe d'un verrou.

En l'occurence ... et en m'écartant du sujet premier, petite réflexion parallèle : je pense que ce verrou pourrait être plus court et dédié à chaque installation de {paquet + dépendances} ... ce qui permettrait logiquement de faire des installations en parallèles sur une même machine.
Exemple d'installation qui en parallèle ne ferait rien exploser, les groupes suivants :

• *les paquets apache2, mysql, phpmyadmin ont une interdépendance donc dans le même groupe

• les paquets firefox, thunderbird ... dont apache2 et mysql et phpmyadmin n'ont que fiche à l'installation (et à l'usage)

Ceci dit ... ta suggestion de proxy cache est très intéresante mais ne répond pas au problème voir dégraderait ce qui est déjà existant.

• Un proxy cache nécessite une machine "serveur".

• Il nécessite de passer par le "réseau" et la notion de goulet d'étranglement de réseau.

• Il nécessite de copier les mêmes paquets dans X machines dans son /var/cache/apt/archive propre en sus de créer un serveur.

En gros le gain du proxy cache est strictement réseau et surtout n'est que de limiter l'usage de la bande passante "internet" (flèche gauche sur le schéma) mais pas l'espace disque global ... et encore moins l'espace disque de la machine hôte des X VM, voir il augmente l'usage de cet espace disque. Mon goulet, c'est pas le réseau.
Hors ... dans ce que j'ai en ce moment, "seul lock fait biiip", je n'utilise qu'une fois l'espace disque : sur l'hôte Windows.
Je ne parle pas de limiter la bande passante du "réseau sur l'hôte Virtualbox" car toutes les VM emploient l'interface "Réseau para-virtuel (virtio-net)" qui, si je ne me trompe pas, va aussi vite qu'un accès disque et est plus rapide qu'une simulation de carte Ethernet 1Gbit/s (enfin je constate qu'il n'y a pas de différence entre un montage SMB et un bon gros montage de vdi pour /var/cache/apt/archive).

J'avais pensé en lisant en biais qu'installer X serveurs apt-cacher sur les X VM clientes permettraient d'indexer X fois chacun de son côté le même répertoire partagé sans aller copier X fois chaque fichier dans un /var/cache/apt/archives dédié, mais en fait, cette solution apt-cacher ne le fait pas.
Donc ... c'est prèsque ce dont j'ai besoin.
Merci encore.

Mes pistes de solutions, pour chaque machine virtuelle :

• monter "à la volée" /var/cache/apt/archives/lock ... si si, monter le fichier lock et pas monter un répertoire dès que celui-ci est nécessaire. Idéalement, le monter en mémoire pour un chouillat de temps et éviter de l'écriture SSD. Ca, je sais pas faire et pourtant ça m'aiderait

• modifier apt / apt-get dist-upgrade -y / synaptic / apt-fast pour qu'ils lancent des installations parallèles et pas seulement des téléchargements ... ou bien trouver un "super-apt-truc" qui installe en parallèle ... mais sans foutre un foutu verrou dans le répertoire /var/cache/apt/archives/lock

Y'a juste un truc qui me chiffonne : infrastructure as code

wow.

Bon, c'est normal, tu n'es pas dans le contexte

Ce n'est pas "l'OS du projet" qui pose problème, mais les OS sur l'infra employée.
Dans sa facette PC "perso", il y a as un dualboot Ubuntu/Windows lambda qui a sa vie propre et ses trucs et bidouilles propres.
Exemple pour toi : après install de ton linux, tu dois sûrement gérer un dual-screen un driver mal foutu et donc bidouiller XF86config, etc ? Imagine que je doive faire cela sur 2 sites (Paris/campagne) et 2 OS, avec un dock eGPU externe sur Paname relié en DisplayPort et un écran de TV 42" 4K en HDMI à la campagne ...
Pour le P50, c'est environ 60 drivers W10Prox64 à installer. Je bousilles une après-midi à installer les drivers. Alors quand je dit 2 semaines .. si ce ne sont pas des jours/homme, c'est plutôt un délai estimatif pendant lequel je marcherai avec toujours un boulet aux pieds le temps d'avoir reconfiguré "comme avant". Je n'ai pas d'iso de l'OS propre car je ne vais pas faire 1 iso d'une machine qui sera réinstallée 5 ans plus tard avec des versions évoluées de logiciel.
Tu vois ... la partie "infra perso", je ne peux pas la scripter, mais j'ai un petit site web en spip dans lequel je note mes bidouilles à refaire "plus tard".

Virtualisation :
Why VirtualBox plutôt que Xen, VMWare, kvm, Hyper-V ?????
Le poid du choix historique fait que seul VirtualBox est l'outil de virtualisation sur mon laptop.
VBox est le plus facile pour lancer mes VM autant sous mon boot Windows que sous mon boot Linux. J'emploie pas VMware du fait de la pérénité et la certitude que je ne passerai pas à la caisse. Va employer KVM sur un hôte Windows, et va employer Hyper-V sur un hôte Linux -pas un guest- ...
En outre, j'ai 1 VM -perso- hors réseau sous Xp qui date de 2005 que je dédie à un seul logiciel : MS-Money 2003, elle a jamais bougé, jamais d'écran bleu, une horloge suisse que cette VM.
J'avais bien tenté de faire cohabiter VBox et Hyper-v ou VMware... mais en fait ils se bagarrent les fonctionnalités VT-X etc.

Docker :
Ce n'est que depuis peu que je teste un produit dont l'infrastructure est livrée sous cette forme et je n'ai pas le choix de ce fou_biiip_tu docker. Alors j'installe mon docker+containers dans des VM virtualbox dédiée ... et comme je cherche même pourquoi ce P$*µ]}^|@ de service docker tombe dans certains cas et pas dans d'autre avec le même modop livré, je multiplie les copies de versions ubuntu et de VM afin de pouvoir en lancer plusieurs en parallèle et voir les différences, fouiner, analyser, tout ça ...
Et ça non plus, ça ne se scripte pas. Enfin pour le moment car c'est un peu ce que je tente de faire.
Peut-être que je pourrais faire un docker qui containairise des dockers plutôt que mettre mes docker dans des VM, mais ... ce serait pareil niveau place et plus de travail à gérer : car à la fin, si et seulement si ça va en prod, il y aura des containers dans 1 docker dans 1 VM.

Je crois que l'idéal serait de pouvoir faire écrire par chaque OS /var/cache/apt/archives/lock dans un FS différent que le FS dans lequel est écrit /var/cache/apt/archives/ et /var/cache/apt/archives/*.
Là, chaque OS guest aurait son lock bien à lui et comme il ne supprime pas les *.deb, et ne fait que les lire, ça ne ferait aucun impact sur les autres guest.
Mais comment monter ça ???
lock en tmpfs pendant que archives/* sont en cifs !

YESSS ! Et plus précisément dans le cas de mise à jour que je souhaitais :

Tout d'abord chaque machine boote en montant dans le fstab du répertoire Windows partagé :

//10.0.2.2/Partage/Apt /var/cache/apt/archives cifs vers=3.0,uid=root,dir_mode=0777,file_mode=0777,credentials=/root/.smbcredentials,iocharset=utf8,_netdev	0	0

Puis, à la queue leuleu de machine en machine :

apt-get update ; apt-get -o "Debug::NoLocking=true" dist-upgrade

Testé en lancement simultané dans 2 VMs Ubuntu Mate 21.04, puis récemment 21.10 dont le répertoire /var/cache/apt/archives a été monté sur le même répertoire de l'hôte Windows C:\Partage\Apt\Archives !

Pour moi, problème résolu.

Merci encore Soshy.

Bonjour,
Je déterre un peu le post du grenier car je l'ai trouvé sur le net en cherchant de la doc sur ce scanner .
Autre lien à consulter ici :
https://forum.ubuntu-fr.org/viewtopic.p … #p21561754
Le Canon lide 220 marche très bien sous Ubuntu 16.04.

Bonjour,
Je tombe sur cette page alors que sous Ubuntu Mate 15.04, j'ai le même problème.
C'était d'autant plus chiant que j'emploie un VirtualBox sous Windows hote pour lancer en guest le Ubuntu Mate installé en dual-boot hote ...

J'ai commencé par la suivre ... sans résultat !

Lien utile : https://bugs.launchpad.net/ubuntu/+sour … +bug/69896
Lien utile : https://forum.ubuntu-fr.org/viewtopic.php?id=362524
Lien utile : https://steftech.wordpress.com/2012/11/ … ntu-12-04/
C'est visiblement encore ces fichus paquets chinois installés defacto depuis la ubuntu 10.xx qui posent problème en laissant ... un paramétrage en_US quelques part.

En voulant installer im-switch (du 3eme lien), j'ai vu qu'il est juste introuvable !
Alors :
Lien utile : http://crunchbang.org/forums/viewtopic.php?id=18200
J'ai fait bêtement : sudo apt-get install ibus ibus-gtk ibus-pinyin
Puis en fait, je me suis aparçu (sans vraiment être certain que c'est l'apt-get qui a donné le résultat) :
Menu / Système / Méthodes de Saisie au clavier
Onglet / Méthode de Saisie
gicler le clavier anglais

.... pas besoin de reboote, je tape en ce moment sous Linux.

Bonjour,
Merci pour te pencher sur mon problème

Je m'en doutais bien un peu ... mais j'espérais.
A la limite, ce n'est pas trop le plus grave pour le moment. Plus tard, j'aurai sûrement un certficat valide de la part de l'hébergeur.

C'est bien TLS et la méthode donnée sur la page dédiée de ubuntu-fr produit bien un certificat SSL.
Du coup, j'ai trouvé une autre méthode ... toujours sur le site de ubuntu-fr, mais cette fois sur la page open-ldap.
Et là, j'ai obtenu un beau certificat TLS chiffré en 3072 bits
Si je n'ai pas encore trouvé complètement, ta remarque m'aura été bien utile et m'aura poussé à chercher un peu plus loin, merci

En effet, ton lien m'a bien donné une astuce ...

cat /var/www/web/html/configuration.php | grep force
	public $force_ssl = '2';

service apache2 restart

2 pour le site et la composante administration emploient le SSL
0 pour aucun emploi du SSL
1 pour seul l'administration emploie du SSL

Sauf que ... dès qu'on a le malheur de changer via le site web, et bien il revient à son défaut initial et refuse de reconnaître le certificat ...
Du coup, je me toujours pose des questions sur l'utilité de cette valeur et si j'ai proprement installé un certificat SSL ...

Edit ... j'aurai dû pousser d'une URL ton lien et notamment celle-ci :
https://issues.joomla.org/tracker/joomla-cms/11735
Il semble que ce soit un bogue spécifique à Apache ... et une solution de contournement a été proposée (modification d'un fichier application.php).
Je ne suis pas certain de bien comprendre où il faut mettre le patch mais après plusieurs tests:.... toujours le même problème.
A la limite, dès lors que c'est un bogue connu et que mon site n'est pas en production...
Case closed et je retourne à mes développements.

Petit correction ... VirtualBox ne supporte vraiment pas plus de 256 Mo de VRAM, je me suis trompé dans mes modifications en mettant 512 Mo dans le fichier de configuration, la correction a fait planter la VM à la relance (768 / 512 / 368 ... seuls 256 Mo sont acceptés).
Donc mon sentiment de gain de performance viens d'ailleurs.

Mais néanmoins, le problème reste entier et la question demeure : quid d'un "gpu"_top ?

Bonjour,
Peut-être que je ne comprends pas précisément ... mais tu nous parles de lancer Firefox ET de lancer un service.
Hors Firefox ne se lance que quand l'interface graphique est lancée ... donc quand le user est connecté.

Donc ton besoin est moins de lancer un script "comme un service unix (via /etc/rcX.d) " que "au lancement de l'utilisateur" .... sauf que là tu veux ton petit shell à toi et pas un soft prémaché par ubuntu ?
Du coup, pour 1 user donné, pourquoi tu le colles pas directement dans

$USER/.config/autostart

Regarde les indicator-power.desktop et autres .desktop pour t'inspirer .... il suffit de modifier le shell de Exec
Si c'est pour tous les utilisateurs ...

/etc/xdg/autostart

non ?

et bien, j'ai fini par trouver une solution ... enfin par trouver ce qui est juste évident : savoir employer avfs.
Alors pour ceux qui se casseront la tête comme moi ... déjà installer avfs (via synaptic)

Installer avfs (via synaptic).
Passer sous root pour faire les manipulations ... ou voir le problème de droits pour $USER
Considérer que ~/.avfs est la racine (un peu comme un chroot) et aller jusque dans le répertoire où se trouve les iso.gz.

$sudo su
$mountavfs
$cd ~/.avfs/media/root/481EA7CF1EA7B3FA/150511_w541/
$mkdir disque
$sudo mount -t auto -o ro,loop w541_sda1.iso.gz\# Disque
$sudo umount Disque
$umountavfs

on a son disque iso.gz monté dans le répertoire : ~/.avfs/media/root/481EA7CF1EA7B3FA/150511_w541/Disque

Ce qui m'induisait il semble en erreur : montage en read-only obligatoire (logique quoi) ET les pages web parlaient de #\ et pas \# à la fin du fichier à monter .... J'interprète que le # est mis pour "voir les fichiers dans le répertoire iso.gz\ ".

Nota que ça peut prendre un - cer - tain - temps à monter ... si le fichier compressé fait 28 Go, mais la partition réelle 480 Go par exemple :/

Bonjour,
Merci pour ta suggestion, mais ça ne correspond pas exactement au besoin.
J'emploi fglrx, j'ai joué déjà sur la fréquence et la vitesse des ventilos.
Pour le moment, j'ai fini par utiliser seulement cela car ça correspond, par exemple.

aticonfig -v --pplib-cmd "set fanspeed 0 4" --od-enable --od-commitclocks --od-gettemperature --effective=now --pxl

Je pourrais ajouter un truc comme cela

Set new Clocks for 0   :  aticonfig --adapter=0 --od-setclocks=770,1126

Mais ça donne plus ou moins de performances ... et pas une limitation d'usage de GPU.

Modifier le code. Idée que je retiens pour le future ... au càs où
En effet ce n'est pas mon programme et cette solutiokn ne s'applique pas.
En outre ... et bien tu fais faire un noop au programme et donc force le programme à laisser du temps à l'ordonnanceur pour passer la main à un autre processus.
Cela veut dire que pendant que le programme a la main ... il tourne toujours à 100 % du processeur, jusqu'à ce qu'il passe la main.
C'est mieux que rien ... mais cela revient à ordonnancer dans le temps avec une préemption forcée (si je me souviens bien), ce n'est pas une limitation de ressources en matière de capacité.
Un peu comme d'appuyer à fond le pied de l'accélérateur et rouler de fait à 100 km/h, puis lever le pied 10 secondes toutes les 30 secondes, de fait redescendre à 50 km/h, pour avoir une vitesse moyenne de 80 km/h .... plutôt que de ne pas appuyer à fond sur le champignon pour toujours rouler à 80 km/h.

Le problème s'est posé pour le cas ou je lance un programme de minage qui a le chic pour bouffer le GPU sauvagement.
Mais je ne veux pas limiter le problème à 1 seul programme en particulier (raison pour laquelle je n'avais pas cité tout de suite le nom du programme car, ainsi que j'ai souvent constaté, tout un tas de monde ne se serait concentré que sur lui sans adopter une vision d'ensemble) et aurait tenté que de résoudre un problème de logiciel de minage que j'ai dont j'ai depuis supprimé le logiciel, sans résoudre mon problème global.

J'ai besoin d'une solution générique de limitation de GPU.
Idéalement ?????
Et bien je veux limiter l'usage du GPU à 80 % de sa performance... même pour Xorg , Unity, LibreOffice, Gimp (qui traite des grosses images), Chrome (qui devient tout gris un temps quand ça télécharge trop d'images)

ps : en outre, tu te doutes que mon besoin se porte sur une solution qui ne s'appliquera pas qu'aux cartes graphiques AMD/ATI, vu que j'ai aussi une nVidia sur un autre PC ........... et un i915 aussi sur un PC portable.

Bonjour,
Je remonter un peu grand-père du grenier car j'avais toujours mon problème ... et que je ne suis pas le seul dans ce cas.

Avant manipulation :

ls /dev/mapper/isw_ebeeiabgeg_Volume1p3 
# / was on /dev/md126p3 during installation
UUID=b60c7e2b-f1f9-4463-976c-5c0a2ca7055f /  ext4  discard,noatime,nodiratime,errors=remount-ro 0    1

ls /dev/mapper/isw_ebeeiabgeg_Volume1p1
# /home was on /dev/md126p1 during installation
UUID=15995653-141b-4a8c-b8e6-376e49fd76e9 /home  ext4    discard,noatime,nodiratime 0  2

après manipulation ...

ls md*
md125  md125p1  md125p2  md125p3  md126  md126p1  md126p2  md126p3  md127

md:
imsm0  Volume0  Volume0p1  Volume0p2  Volume0p3  Volume1  Volume1p1  Volume1p2  Volume1p3
ls mapper*
control

En fait la manipulation était de modifier

gedit /etc/default/grub.d/dmraid2mdadm.cfg
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT nomdmonddf nomdmonisw"
par
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT nomdmonddf"

Les liens qui m'ont mis la puce à l'oreille ...
https://raid.wiki.kernel.org/index.php/RAID_setup
http://ubuntu.5.x6.nabble.com/Dmraid-to … 57892.html
http://package-import.ubuntu.com/diffs/dmraid
http://ubuntuforums.org/archive/index.p … 64766.html

Si je comprends bien, la Ubuntu, par défaut et au boot impose de "ne pas utiliser" une sorte de protocole de compréhension de raid qui est "ISW" vs un fameux "DDF".
Il y aurait un état de transition au sein des distributions.
L'ancien format étant /dev/md126p1 et le nouveau /dev/mapper/isw_ebeeiabgeg_Volume1p1 ...
Mais si on regarde un code source, on voit que systématiquement, le fait d'interdir IMSM fait un warning désagréable ...
En en sus, ça fait dans /var/log/dmesg.0 des erreurs du type :

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-33-generic root=UUID=b60c7e2b-f1f9-4463-976c-5c0a2ca7055f ro elevator=deadline allow-discards root_trim=yes CONFIG_HZ=1000 nomdmonddf nomdmonisw


[   10.838835] systemd-udevd[887]: conflicting device node '/dev/mapper/isw_ebeeiabgeg_Volume0p1' found, link to '/dev/dm-1' will not be created
[   10.902668] systemd-udevd[878]: conflicting device node '/dev/mapper/isw_ebeeiabgeg_Volume1p1' found, link to '/dev/dm-5' will not be created
[   10.927433] systemd-udevd[879]: conflicting device node '/dev/mapper/isw_ebeeiabgeg_Volume1p2' found, link to '/dev/dm-6' will not be created

Bref ... la transition ne serait pas au point.
En giclant le nomdmonisw, et bien on reviendrait à la vielle mode sans les warning.