Ubuntu-fr

J'ai fini part trouver comment activer le clonage d'écran sur Ubuntu 12.04. C'est presque aussi simple qu'une notice d'utilisation chinoise....

Donc,
* Brancher le second ecran/videoprojecteur/whatever
Dans la fenêtre Affichage
* Dévalider l'ecran/videoprojecteur/whatever
* Appliquer et valider
* Faire glisser les 2 écrans l'un sur l'autre
* Appliquer et valider
* Revalider l'ecran/videoprojecteur/whatever
* Appliquer et valider

Le paquet x11-common permet de lancer certaines applications graphiques sur un serveur qui n'a pas de couche graphique.

logwatch fait ça

aptitude install logwatch

Comment tu détectes qu'il y a de nouveau des utilisateurs, avec un serveur éteint ?

smartctl -H /dev/sda

En moins synthétique avec l'option -a (--all) à la place. tu peux jouer avec les diverses options inclues dans le -a pour mettre les infos précises que tu souhaites y voir.

* Gestion des licences logicielles => A la mano et au feeling
    * Gestion des stocks / inventaire  => GLPI
    * Gestion des alertes => Nagios/Centreon
    * Gestion des configurations de postes/serveurs => Puppet (avec foreman en cours)
    * Déploiement des postes/serveurs => kickstart et plus tard foreman quand tout sera au point
    * Gestion du SLA => Nagios/Centreon
    * Gestion de cluster de serveurs

La ça regroupe pas mal de choses pour nous, donc

- Pour la partie HA => VMWare (en cours d'install), on a aussi fait du corosync/pacemaker, avec parfois DRDB, mais c'est en train d'être abandonné
- Pour la partie cluster de calcul => OAR

    * Gestion des tickets utilisateurs => le mail, le téléphone ou le toc toc à la porte du bureau
    * Gestion des mots de passe des serveurs => On vénère Arioch le dieu du Chaos qui lui seul doit avoir une vue d'ensemble de la gestion des mots de passe sur nos serveurs

La virtualisation et la distribution de machine virtuelles (virtualbox ou VMWare) me semble bien bien plus simple à mettre en œuvre.

Tu vas être tributaire de la gestion de la sécurité de tes clients. Quel que soit la solution que tu imagines si tu n'es pas maître de l'infrastructure, elle risque de ne pas fonctionner.
Certains compte interdisent le boot sur USB ou tout autre chose que le disque de l'ordinateur et le bios est verrouillé afin de ne pas pouvoir y toucher. Tu pourras aussi te heurter au filtrage interne qui font que ta démo ne sera visible que pour certains postes, voire aucun. Le réseau peut être segmenté et filtré d'une manière que ni toi ni tes contacts ne pourront modifier.

A mon avis ton premier problème n'est pas technique mais organisationnel. C'est à dire d'établir un cahier des charges que le client doit impérativement remplir afin que tu puisses faire tourner ta démo. A partir de ce que le client peut accepter, tu pourras ensuite trouver la solution technique qui rentre dans les clous.

Tu peux installer directement les imprimantes dans CUPS et lier SAMBA et CUPS, dans ce cas, c'est le serveur samba qui  possède les pilotes Windows pour les imprimantes, donc tu n'a rien besoin d'installer coté client. Tu peux regarder du coté de la commande cupsaddsmb.

Si l'imprimante est installée sur le poste, les utilisateurs pourront imprimer en direct, la solution (complexe) est de mettre les imprimantes dans un autre VLAN accessible uniquement par le serveur CUPS/SAMBA, l'autre solution (simple) est de mettre des ACL sur les imprimantes et de n'autoriser l’accès qu'à partir du serveur d'impression, bien sur il faut verrouiller le panneau de commande de l'imprimante

Non non, il peut parfaitement écouter sur 2 ports avec la même configuration, tel que l'a présenté zspider. Dès que tu déclares des utilisateurs dans AllowUsers si tu veux te connecter avec le compte root, il faut en plus du

 PermitRootLogin Yes

, rajouter root dans AllowUsers.

Par contre ne pas oublier d'ajouter des règles dans ton firewall, par défaut ssh écoute sur le port 22 et si tu veux utiliser des ports différents pense à les ouvrir dans ton firewall. Sinon aussi pour que tes modifications dans /etc/ssh/sshd_config soient prises en compte n'oublie pas de redémarrer le serveur ssh

Pour tester si tout se passe bien avec tes utilisateurs tu peux faire un ssh sur localhost, ce qui te permettra de t’affranchir des configurations réseaux

ssh -p 21569 user2@localhost

Pour chrooter les utilisateurs, tu peux essayer ça en remplaçant par les infos qui t’intéressent comme par exemple Match Group user2

Modifier le fichier /etc/ssh/sshd_config

Subsystem sftp internal-sftp

UsePAM yes

SyslogFacility AUTH

Match Group users
        ChrootDirectory /home
        AllowTCPForwarding no
        X11Forwarding no

Redémarrer le service ssh

Effectivement

Les VPS de chez OVH par exemple ne permettent elles pas de s'affranchir du coté haute dispo ? Certes elles ne répondent pas à la question de l'accès rapide aux données, tu as parfaitement raison. Et avec Linux même sur un tout petit serveur virtualisé, on fait déjà des miracles

C'est vrai aussi. Tu vendrais pas un peu ton affaire là

Le forfaitaire, c'est l'installation de la solution de supervision (logicielle et matérielle) seul ou en plus la surveillance et intervention en 7/7 24/2, ou plus raisonnablement en heures ouvrées 5 jours sur 7 ?
A l'époque ou j'avais bossé dans cette branche, les tarifs pour la supervision à distance de l'infra était plutôt salés, mais bon on bossait pour des grosses structures aussi. L'avantage d'externaliser les serveurs, c'est que dans les datacentre, la surveillance et intervention est comprise dans la location du serveur, en plus de la clim du courant ondulé et des sauvegardes.