Dans le cas d’une utilisation multimédia d’un PC sous Gnu/Linux (ici Ubuntu 11.10), une bonne télécommande est très utile, je vous propose ici d’utiliser votre smartphone sous Android en tant que tel.

Nous allons ici détailler la procédure pour contrôler l’application VLC de votre machine sous Gnu/Linux et plus spécialement Ubuntu à partir d’un smartphone sous Android.

Pour cela, nous allons commencer par configurer VLC afin de pouvoir le contrôler via l’interface HTTP:

• Configuration l’interface principale (ou secondaire) de VLC sur HTTP:
  • Se rendre dans les préférences de VLC et activer l’interface HTTP en tant qu’interface principal:

  

• Lancez VLC depuis le PC en utilisant le paramètre suivant afin de lancer l’interface HTTP en tant qu’interface secondaire (option « -I http » pour la lancer en interface primaire):

  vlc --extraintf=luahttp

ou un exemple plus complet chargeant automatiquement une playlist ou une liste de chaines TV et utilisant un affichage au ratio 16/9:

  /usr/bin/vlc chaines.conf --aspect-ratio=16:9 --extraintf=luahttp

Editez ensuite le fichier /usr/share/vlc/http/.hosts en y ajoutant l’adresse IP de votre smartphone (ou la plage d’adresses IP que vous souhaitez autoriser à accéder à l’interface HTTP de votre VLC):

VLC Remote

  # Access-list for VLC HTTP interface
  # $Id$
  192.168.0.0/16

Vous êtes maintenant prêts du côté du PC, passons donc à l’installation du nécessaire sur le smartphone.

• Installation de l’application gratuite Remote for VLC sur votre smartphone Android depuis le Market:
  • Cliquez ici pour installer Remote for VLC sur votre smartphone Android.

Vous pouvez également scanner le QR code présent à droite depuis votre smartphone pour retrouver directement l’application sur le market:

Une fois l’application installée, configurez les données de votre serveur (adresse IP, port (par défaut 8080), nom, …).

Vous pouvez désormais accéder à vos playlist, changer de chaine, gérer le volume, passer en plein écran, …

Si cela ne fonctionne pas, pensez à vérifier votre pare-feu, il faut que votre smartphone puisse joindre votre machine sur le port choisi dans la configuration de VLC (par défaut 8080).

D’autres solutions existent, si vous en connaissez de meilleures, plus simples ou souhaitez apporter des informations supplémentaires, n’hésitez pas, utilisez les commentaires et/ou la page du blog Libre-Astux sur G+, ils sont là pour ça.

Il y a une autre application qui m’a semblé interressante, SSHmote qui permet de controler diverses applications multimédia à travers une connexion SSH, cependant, cette application bien que proposant la gestion de diverses applications telles que Kaffeine, VLC, MPlayer, … ne m’a pas convaincu car celle-ci ne permet en fait que la navigation dans mes repertoires et me propose la lecture des fichiers audios, … mais pas le lancement d’une playlist ou d’un fichier chaines.conf. De plus, après un test et un rapide contact avec les développeurs, la gestion des mot de passe dans l’application SSHmote n’est pas sécurisée.

Sources:

maketecheasier.com/remote-control-vlc-with-android-phone/2010/08/06

www.appbrain.com/app/org.peterbaldwin.client.android.vlcremote

Étiquettes: android, ConnectBot, remote, ssh, vbetool, vlc, VLC Remote, Wake On Lan, xset

Pour allumer ou éteindre votre écran de PC à distance et notamment depuis votre smartphone, nous allons utiliser des commandes liées à DPMS et ssh. (Le PC utilisé est équipé d’Ubuntu 11.10 avec OpenSSH)

• Plusieurs commandes possibles,notamment xset et vbetool.

  xset dpms force on ' Force le rétroéclairage de l'écran.

  xset dpms force standby ' Force l'arrêt du rétroéclairage de l'écran.

  sudo vbetool dpms on ' Force l'activation du rétroéclairage (fonctionne également via SSH)

  sudo vbetool dpms standby ' Force la désactivation du rétroéclairage (fonctionne également via SSH)

• Si vbetool n’est pas installé sur votre poste (par défaut sur Ubuntu il ne l’est pas), utilisez simplement la commande suivante:

  sudo apt-get update && sudo apt-get install vbetool

• Il est possible d’autoriser l’utilisation de sudo sans mot de passe pour cette commande en ajouter la ligne suivante au fichier /etc/sudoers:

  %admin ALL=(root) NOPASSWD:/usr/sbin/vbetool

• Pour simplifier l’utilisation de ces commandes, ajoutez les alias suivants à votre fichier ~/.bash_aliases (après l’avoir activé si nécessaire dans ~/.bashrc):

  alias off='sudo vbetool dpms standby'

  alias on='sudo vbetool dpms on'

• Afin de pouvoir utiliser ces commandes depuis notre smartphone Android, il nous faut y ajouter un client SSH.

Le client SSH gratuit ConnectBoT fera l’affaire, vous pouvez le retrouver ici ou utiliser le QR code correspondant à droite, il suffira ensuite de se connecter puis de lancer la commande on ou off pour allumer ou éteindre l’écran. Cela fonctionne avec tout type de smartphone ou depuis un PC client pour peu que celui-ci dispose d’un client SSH et que votre serveur SSH soit accessible.

Sources:

https://market.android.com/details?id=org.connectbot&hl=en

createqrcode.appspot.com/

Étiquettes: android, dpms, ssh, ubuntu, vbetool, xset

En ouverture de ce billet, je vous souhaites à toutes et à tous mes Meilleurs Voeux, une Bonne (dernière ??) Année 2012 et une Excellente Santé. Continuez à venir nombreux visiter ce blog et y retrouver toutes sortes d’astuces.

Aujourd’hui, un petit problème pas bien gênant mais qui fait perdre du temps inutilement.

Depuis la migration de mon poste sous Ubuntu 11.10 avec l’interface Unity, j’ai vu apparaître des incohérences dans la gestion des associations de fichier.

Le problème se limitant à l’ouverture des fichiers depuis mon navigateur (au départ Firefox puis Chromium) qui au lieu de m’ouvrir le fichier concernait m’ouvrait systèmatiquement mon navigateur de fichier (Nautilus) à l’emplacement du fichier.

L’ouverture du fichier en lui-même se faisait tout à fait normalement et dans la bonne application en exécutant le fichier depuis Nautilus. J’ai donc pensé au départ qu’il s’agissait d’un problème de configuration de Firefox mais il n’en est rien.

Pour résoudre le problème, il suffit de supprimer le fichier « ~/.local/share/applications/mimeapps.list » via la commande suivante:

rm ~/.local/share/applications/mimeapps.list

Cela permet de résoudre les problèmes d’association de fichiers lorsqu’ils sont lancés notamment à l’aide de la commande xdg-open par une autre application du système.

Ainsi après suppression du fichier, l’ouverture d’un document pdf (par exemple) depuis chromium ou firefox ouvre directement celui-ci dans le lecteur pdf approprié et non plus Nautilus à l’emplacement du fichier.

Source: Forum Ubuntu-fr

Étiquettes: association, chromium, extensions, fichiers, firefox, Nautilus, ubuntu, unity

Utilisant de plus en plus Pluxml dans la mise en place de sites web et de blogs, je me suis renseigné sur la possibilité de mettre en place un login OpenID pour atteindre la zone d’administration.

N’ayant rien trouvé de concret, j’ai décidé d’implémenter moi-même cette solution d’authentification sur la plateforme Pluxml 5.0.2 à partir de la librairie php-openid.

Vous pouvez donc trouver en bas de cet article, le patch sous forme d’archive applicable à pluxml 5.0.2 afin de pouvoir utiliser l’authentification OpenID.

Cette archive n’est pas un plugin, son application sur une installation opérationnelle de Pluxml 5.0.2 n’est pas sans risque ! N’oubliez pas d’effectuer une sauvegarde avant tout test.

Cette archive ajoute et modifie certains fichiers du répertoire /core/admin de pluxml. Ce patch ne peut être installé directement que sur une installation propre de Pluxml 5.0.2 ou si aucun des fichiers modifiés par ce patch dans /core/admin n’a été précedemment modifié pour vos besoin personnels. Dans le cas contraire, veuillez plutot décompresser l’archive dans un répertoire temporaire et adapter vos modifications sur ces fichiers (ou inversement).

Voici le détails des modifications apportées:

• Intégration de l’authentification OpenID
• Ajout d’un profil Contributeur qui permet la saisie d’articles et nécessite la validation de l’administrateur ou d’un modérateur pour la publication
• Possibilité d’automatiser la création des utilisateurs depuis leur OpenID avec automatiquement un profil de contributeur

Les fichiers affectés se situent tous dans /core/admin.

Fichiers et librairies ajoutés:

• Auth => La librairie php-openid
• const_openid.php => déclaration des constantes nécessaires (et personnalisation par site)
• login_openid.php => Page d’authentification pour OpenID
• verify_login_openid.php => Affectation de l’utilisateur à partir de son identifiant OpenID
• img/social-icon.png => Set d’icones pour la page d’authentification

Fichiers modifiés:

• auth.php => Page principale d’authentification, ajout de l’appel à la page « login_openid.php »
• prepend.php => Ajout du profil « Contributeur »
• top.php => Ajout d’un filtrage et configuration du profil « Contributeur »
• parametres_users.php => Configuration du profil par défaut sur « Contributeur »
• medias.php => Restriction, interdiction pour le profil « Contributeur »
• article.php => Désactivation des options de publication pour le profil « Contributeur »
• admin.css => Ajout de l’affichage nécessaire pour le cadre d’authentification OpenID

Un installation demo est accessible à l’adresse suivante:

• demo.libre-astux.info
• demo.libre-astux.info/core/admin

Cette version étant toute fraiche, seuls l’authentification OpenID de Google et d’Orange ont été testées et sont fonctionnelles. Si vous utilisez un autre provider OpenID (ou votre propre provider OpenID), une fois connecté sur l’interface de demo, vous avez directement un accès contributeur et pouvez donc rédiger vos commentaires dans un article dont seul vous et moi-même avez accès. Si certains contenu de ces articles sont pertinents, je les mettrais en ligne afin de permettre à tous d’en profiter.

L’archive permettant le patching de Pluxml version 5.0.2 est disponible ci-dessous:

• pluxml-patch-openid.tar.gz

L’application du patch est très simple, il suffit de vous placer dans le répertoire parent de pluxml (par exemple /var/www) puis de décompresser l’archive via la commande suivante:

tar -xvzf pluxml-patch-openid.tar.gz

Une fois le patch appliqué, lorsque vous vous rendrez sur l’écran de connexion à la zone d’administration, vous devriez obtenir ceci:

Vous pouvez désormais vous connecter en cliquant sur l’un des pictogrammes correspondant à votre provider OpenID ou saisir votre url OpenID si votre provider n’est pas listé.

Comme toujours, n’hésitez pas à laisser vos commentaires, que ce soit sur ce blog ou sur le blog de demo correspondant à cet article.

Ressources:

• Soyer votre propre fournisseur OpenID
• Ressources Pluxml
• Librairie Php-OpenID

Étiquettes: développement, implémentation, openid, patch, pluxml

J’ai récemment migré mon poste de test vers Ubuntu 11.04 (Natty Narwhal, version Alpha 3, Amd64), comme d’habitude, non pas une installation complète mais une mise à niveau via la commande:

update-manager -d

qui permet de mettre à jour le système vers la version de développement.

Une fois la mise à niveau effectuée, l’interface graphique ne s’est pas relancée automatiquement, problème lié au pilote nvidia précédemment utilisé. Une fois le fichier de configuration de xorg renommé à l’aide de la commande suivante:

sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.old

Gdm ne se lance pas tout seul, je relance gdm dans les services au démarrage (désactivé automatiquement lors de la mise à niveau ???):

sudo update-rc.d -f gdm defaults

Puis suit un redémarrage du système, je retrouve enfin mon écran de login. Une fois logué (session classique), je reconfigure le pilote nvidia via l’interface graphique en exécutant nvidia-xconfig puis nvidia-settings.

Je retrouve l’usage de mes 2 écrans en twinview (bureau en continu sur les 2 écrans).

Autres problèmes:

Unity:

Sur mon poste et malgré plusieurs tentatives, impossible d’utiliser l’interface « Unity » pourtant configurée en tant qu’interface par défaut lors du login (choisir « interface classique » au login pour basculer sur gnome)

Firefox 4:

Incompatibilité de profil entre Firefox 3.6 et Firefox 4, impossible de lancer Firefox 4 même en safe mode, j’ai du renommer mon profil afin qu’un nouveau puisse être crée. j’ai ensuite réimporté mes favoris sur celui-ci.

mv /home/user/.mozilla /home/user/.mozilla.ff3_6

Une fois cette manipulation effectuée, Firefox 4 se lance sans problème. La restauration des favoris se fait via le gestionnaire de bookmark => Import => Sélectionner le dernier fichier de backup dans le profil « .mozilla.ff3_6″.

Pour le reste, tout semble fonctionner convenablement hormis quelques freeze complet (arret disques durs + perte clavier et souris) de temps en temps, problème récurrent sur ce poste depuis Ubuntu 9.10. (spécifique à la version 64 bits)

Pour test, une Debian Squeeze est également installée sur ce poste, sur le même disque dur et avec les même applications, je n’ai pas le moindre problème de freeze.

Certains d’entre vous ont déjà testé cette future version d’Ubuntu, d’autres s’y interressent et se demande s’ils peuvent franchir le pas avant la mise à disposition de la version finale. Cette version ne me semble pas encore suffisamment stable pour ceux qui ne s’y connaissent pas suffisamment en ligne de commande. De plus Unity proposé comme interface par défaut est encore loin d’être opérationnel sur cette version en tout cas.

Si vous rencontrez d’autres problèmes spécifiques, que vous ayez ou non trouvé une solution, venez partager votre expérience en laissant un commentaire afin de recenser les problèmes les plus fréquents avec cette nouvelle version (La version beta 1 est prévue pour le 31 mars 2011 pour une version finale le 28 avril 2011).

Étiquettes: alpha 3, firefox, problèmes, test, ubuntu 11.04, unity

Nos données étant de plus en plus souvent stockées sur des supports distants, il peut être nécessaire de donner accès à un lecteur réseau à notre serveur Apache.

Cette opération se révèle extrêmement facile sur un système Gnu/Linux puisqu’il suffit de créer un point de montage sur le système et d’autoriser son accès via la configuration d’Apache:

Monter le lecteur réseau automatiquement via fstab (y ajouter la ligne suivante):

//192.168.0.10/apache /mnt/netdrive smbfs rw,user,uid=1000,gid=1000,credentials=/etc/samba/pub.cred 0 0

user = n’importe quel utilisateur peut monter et démonter le partage
uid,gid = à qui appartient le partage (par défaut root.root avec les droits 755 donc un utilisateur ne peut écrire par défaut dans le partage)
credentials = on met pas l’utilisateur et le mot de passe en clair dans fstab mais dans un fichier /etc/samba/pub.cred (protégé en lecture lui)

le fichier pub.cred contient:
username=Domain\Apache
password=motdepasseassocie

source: Monter un partage Samba avec fstab de Jérome Hanoteau

Configurer les droits d’accès depuis Apache (/etc/apache2/sites-available/default ou autre), il faut ajouter les lignes suivantes (à adapter) entre les balises VirtualHost souhaitées:

1
2
3
4
5
6
7

Alias /netdrive/ "/mnt/netdrive/"
<Directory "/mnt/netdrive/">
    Options -Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

En revanche sous Windows, impossible d’accéder à un lecteur réseau depuis Apache avec une configuration par défaut. Et pour cause, par défaut le serveur Apache est lancé en tant que service par l’utilisateur « System », or cet utilisateur ne peut accéder aux partages réseaux.

La solution apparait donc simplement, il suffit de modifier le compte avec lequel le serveur Apache est lancé. Il faut remplacer l’utilisateur « System » par un utilisateur du domaine ayant les droits nécessaires sur les répertoires concernés. Pour la suite nous utiliserons donc l’utilisateur « domain\Apache ».

Les étapes:

• Win+R
• Services.msc
• Clic droit sur « Apache »
• Onglet « Log on »
• Modifier le compte comme sur l’image ci-contre
• Valider

• Ajouter les droits sur les répertoires nécessaires au fonctionnement d’Apache pour cet utilisateur:
  • C:\Program Files\Apache Software Foundation\Apache2.2
  • C:\Windows\temp

Pour ajouter les droits sur un répertoire, il faut effectuer un clic droit sur celui-ci puis « Propriétés » puis dans l’onglet « Security », ajouter l’utilisateur souhaité et lui donner les droits souhaités (lecture, écriture pour les répertoires locaux nécessaires à Apache, lecture et/ou écriture pour les lecteurs réseaux en fonction des besoins).

Il faut également effectuer cette opération sur les répertoires réseaux que l’on souhaite lui rendre accessible.

/!\ !!! Nous touchons ici à la gestion des droits d’accès, veillez à ne pas fournir trop de droits à cet utilisateur afin de limiter l’impact en cas d’erreur dans la configuration (utiliser un utilisateur de base de votre domaine et ne lui donner accès qu’aux répertoires nécessaires). !!! /!\

N’oublions pas de relancer le service Apache une fois ces modifications effectuées afin de valider le fonctionnement du serveur avec ce nouvel utilisateur.

Nous passons ensuite à la configuration d’Apache à proprement parler, comment rendre accessible ce fameux lecteur réseaux ?

Contrairement à ce que l’on pourrait penser, il est impossible de dire à Apache d’utiliser un lecteur réseau identifié par une lettre. De même, la gestion des droits à ce répertoire doit se faire au niveau Windows et non dans la configuration d’Apache.

Ainsi au niveau de la configuration d’Apache lui-même, rien de spécial. Il est possible d’ajouter un alias pour faciliter les choses mais ce n’est pas obligatoire.

Alias /netdrive/ « //192.169.0.10/apache/ »

Il suffit ensuite d’utiliser soit le chemin réel, soit l’alias dans notre code PHP ou autre afin d’accéder à ces données.

Exemple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
// Affiche le contenu d'un fichier sur le réseau et déplace celui-ci
$rep = "//192.169.0.10/apache/";
$annee = date("Y");
$dest_rep = "//192.169.0.10/apache/$annee";
$dir = opendir($rep);
while ($f = readdir($dir))
{
   if(is_file($rep.$f))
   {
     echo $f;
     rename($rep.$f, $dest_rep.$f);
   }
}
?>

Étiquettes: apache, domaine, droits accès, lecteur réseaux,