skimpax a écrit 14 commentaires

Utilisateur de Proxox VE à titre personnel, c'est une excellente nouvelle que cette nouvelle version de Proxmox :
- elle est basée sur Debian Jessie au lieu de Wheezy donc une base logicielle beaucoup plus récente.
- abandon de OpenVZ au profit de LXC. OpenVZ imposait à Proxmox d'utiliser au noyau 2.6.32 car les noyaux plus récents ne supportent pas OpenVZ.

Pour ce dernier point c'est donc coup double : on va enfin avoir un noyau récent (donc plus de HW supporté) et passage à LXC qui est est une technologie toujours en développement actif. A l'opposé d'OpenVZ où c'est RedHat qui assure la maintenance pour que "la fin de vie" se passe au mieux.

Bref, c'est un nouveau souffle pour Proxmox VE…

s/Plusieurs projets ont déjà chercher/Plusieurs projets ont déjà cherché/

Je ne pense pas qu'il y ait eut erreur avec "user plane" : c'est par opposition à "control plane". C'est du "langage" du domaine telecom.
Le "user land" c'est du domaine informatique (plus particulièrement du noyau Linux).

Pour tous les systèmes installés à partir de fichiers images issus du net (et non pas via l'installeur Debian), une bonne pratique est de systématiquement re-générer de nouvelles clefs SSH.

Cela se fait tout simplement avec ces deux lignes (Debian) :

rm -f /etc/ssh/ssh_host*
dpkg-reconfigure openssh-server

Dans le rendu final sur le site, il manque une partie du code, donc le script plante.

Cependant, l'ensemble du code est bien présent dans le code source de cette page web et d'ailleurs la prévisualisation s'effectue correctement : tout y est. J'avais vérifié avant de poster quand même !

Seul le rendu final tronque la fin du script. Je ne sais pas pourquoi. Un modérateur/habitué pourrait-il me donner une piste ?

A suivre donc…

PS :
Le code passe le pep8 (sauf critère de longueur de ligne).

Le code présent mais pas affiché :

        return self.dispatch(argsdict.keys())

    def dispatch(self, args):
        """ Call controller action """
        for cmd in args:
            # retrieve callback associated to cmd and execute it, if not found
            # display help
            return self.cmdCallbacks.get(cmd, self.parser.print_help)()


if __name__ == '__main__':
        controller = FreeboxOSCtrl()
        cli = FreeboxOSCli(controller)
        rc = cli.cmdExec(sys.argv[1:])
        sys.exit(rc)

Bonjour,

J'ai modifié le script pour lui rajouter la fonctionnalité de reboot de la Freebox.
Tout est là :
http://linuxfr.org/forums/programmationshell/posts/controle-de-la-freebox-v6-par-le-shell-wifi-reboot

Je suis l'auteur initial de ce script shell et il fonctionne toujours chez moi :-))

Concernant le reboot à distance, je vais essayer de voir si c'est possible…

J'utilisais une carte Atom N330 dual core (le prédécesseur du D510) avec 2GO de RAM.
Aucun soucis avec.

Depuis, j'ai voulu pouvoir faire de la virtualisation, j'ai donc changé de carte mère car l'Atom de possède pas les instruction de virtualisation en hardware (qui sont indispensables pour KVM). J'ai donc opté pour une AMD e-350, avec 8GO RAM. J'en suis ravi : refroidissement passif, virtualisation, économe (consomme pas plus que mon ancienne atom).

La virtualisation, c'est plus pour la souplesse qu'un besoin réel : cela permet de créer une machine virtuelle le temps de prototyper, 'pour bidouiller' et passer ensuite sur une autre VM propre celle-ci pour y mettre la solution définitive.

Pour gérer ces VM, j'utilise Proxmox v2 et tout ce fait via une interface web. Proxmox sait faire des VM (via KVM) ou des conteneurs (via OpenVZ). Proxmox est libre et la v2 est basée sur Debian Squeeze.

Le Wifi, de part sa conception radio n'est pas des plus économe : il n'a pas été conçu initialement pour de l'embarqué.
Un palliatif a été de corriger cela au niveau logiciel, avec gestion de la mise en ville du wifi si non utilisé (si aucun trafic envoyé).
Bref, le wifi est plus dédié à un 'dongle', sous entendu qu'il y a un équipent derrière avec une batterie d'une certaine capacité déjà (ex. un ordinateur portable) et non pas une batterie de très petite capacité, type téléphone mobile.
C'est en cela surtout que les techno radio de téléphonie mobile sont bien meilleures : elles ont directement été pensées pour une utilisation nomade, avec une petite batterie.
Par exemple, la radio 4G LTE est encore optimisée par rapport à la 3G, notamment en 'uplink'.

Sur un ordinateur portable, si il y a beaucoup de trafic (eg nombreux téléchargements), alors la consommation du wifi sera non négligeable. A contrario, si le wifi est peu utilisé et que la gestion d'énergie du wifi est activée, cela ne devrait pas être sensible.

Après mise à jour du script, cela fonctionne parfaitement maintenant : plus aucune pollution sur le stdout.
Le script présenté en première page été mis à jour avec les dernières modifications.
BFG, merci pour le tuyau :-)

Merci pour le tuyau, j'essaierai dès ce soir...

Cette crontab n'est qu'un exemple et n'est pas la mienne. Cependant, effectivement, je ferme le tuyau à 22h : mes enfants n'étant pas encore ados, je m'auto-censure en coupant à 22h ;-)

Parmi les nombreux projets du WCG, l'un est dédié à la dystrophie musculaire : Help Cure Muscular Dystrophy - Phase2, qui accessoirement est une initiative française (AFM, CNRS, Université P.M. Curie).
Plus d'info ici : https://secure.worldcommunitygrid.org/research/hcmd2/overview.do?language=fr_CA.

Et pourquoi pas utiliser FreeNAS ?
http://sourceforge.net/projects/freenas/

Je l'utilise depuis 2 ans à titre perso en RAID1 et une carte mère basée sur un ATOM et 2GO de RAM. Au plus, j'ai utilisé 13% de la RAM (de mémoire).

Tu configures tout via une interface web (francisée également) :
http://sourceforge.net/apps/gallery/freenas/index.php?g2_ite(...)