Edito

Evidemment, s'il n'y a pas de solution, c'est qu'il n'y a pas de problème. ;o))

samedi 19 septembre 2015

Sauvegarder le NAS Synology sur un simple partage Réseau


Evidemment, la mise en place d’un plan de sauvegarde efficace est primordiale pour assurer la sécurité et l'accès des données même sur un NAS Synology ( récemment, un Synology de ma connaissance à mis 2jours à refaire son FileSystem = 2 jours sans accès à 30To non sauvegardé, faut pas être pressé par le temps !!! ) .
Synology propose de base plusieurs solutions de backup ( Le Cloud vers 4 ou 5 Services / En local sur un Disque USB ou eSATA ) . Pour les sauvegardes réseau, là c'est soit un autre Syno ou un serveur compatible Rsync ........
Ok, mais si je veux sauvegarder incrémentalement juste sur un point de partage réseau ( genre ma TimeCapsule ou un vieux NAS sans Rsync ) ???? Ha ben non, mon bon mossieur ya pas ( ou j'ai pas trouvé ... )...
Bon, de la un constat simple :
Un synology, c'est un linux ( & de la, il ya une solution a trouver, c'est sûr ... )
Sur un linux il y a normalement rsync & cron ...
Sur un synology on peut monter automatiquement un dossier distant ....
- Avec tout ça on devrait y arriver, Non ??? ( il y a sans doute aussi avec ipkg sur le syno d'autre solutions, mais on va plutôt essayer de faire au plus simple avec le NAS de base .. )

MONTAGE du point de partage Distant
Dans l'interface web du Syno, on fait un nouveau Dossier Partagé, on gère les droits les partages .....
On lance le File Station et on Monte le dossier Distant ....


C'est en CIFS ( SMB quoi ... ) le mode client du Syno . Pour les autres protocoles ( ZFS ou AFP, je pense qu'il faut bricoler le linux, mais la on fait simple .....



Dossier : \\Adresse\Dossier
Nom de compte: user
Mot de passe: mdp
Mapper sur: /volume1/TOTO

FABRICATION du SCRIPT de Sauvegarde
On dégaine Atom, nouveau Fichier, puis on écrit vite fait :
!/bin/bash
# SCRIPT de Sauvegarde
rsync --archive --verbose --progress --delete -E /volume1/Source( le Dossier du syno à Sauvegarder )/ /volume1/Destination( Le point de montage Distant que l'on à fait plus Haut )
On Sauvegarde avec un point sh dans un dossier partagé du Syno ( un dossier SCRIPT par exemple )

TEST Rapide
Se connecter en root au NAS.
Il faut bien sûr avoir activé le service ssh au préalable, par l’interface web du NAS. Pour se connecter en ssh, c’est comme toujours, depuis un terminal :
ssh root@ip.de.syno
STATIONnas> 
On passe root (#)
su root
#
On teste 
# cd /volume1/SCRIPT/
# Jobdesynchro.sh
Et là ça ne fonctionne pas !!!
Ben oui, sur un syno, il faut bien lui dire correctement :
/bin/sh /volume1/SCRIPT/Jobdesynchro.sh
Et ça fonctionne !!! C'est comme ça que l'on écrira notre lancement de script dans le CRON.
3 petits test de plus ( effacement de fichiers, d'un coté, de la'autre pour être sur que notre Rsync est OK - pour le reste : Doc Rsync ) Ok, ça tourne, le script est Bon .

Le CRON du Syno
Sur un Syno, il faut modifier le fichier /etc/crontab et pour effectuer la prise en compte de ces modifications ( On est sur un DSM 5, sur le 4 c'est presque pareil, mais les commandes de relance sont différentes et au redémarrage il restaure le etc.default/crontab, donc il faut aussi changer celui-ci, a priori ) :
crond stop
# crond start
Pour la modification du crontab on utilise vi ( manuel de survie ) & on rajoute notre ligne de script .
vi /etc/crontab
#minute hour    mday    month   wday    who     command
0       0       1       *       *       root    /usr/syno/bin/syno_disk_health_record
8       2       *       *       1,2,3,4,6       root    /usr/syno/bin/synopkg chkupgradepkg
0      0      *       *       *       root    /bin/sh /volume1/SCRIPT/Jobdesynchro.sh
~
Alors autre subtilité pour la modification du crontab du Syno, il n'accepte que des Tabulation entre les champs, donc dans vi on ecrira notre ligne comme ça ( après un coup de 'i' ):
0/TAB/0/TAB/*/TAB/*/TAB/*/TAB/root/TAB//bin/sh /volume1/SCRIPT/Jobdesynchro.sh

Il reste juste a redémarrer et regarder si le crontab a bien gardé notre ligne ( sur DSM 5.1-5022 Update 3, ça tient mais c'est remonté dans les lignes de la crontab, j'avais d'autre scripts depuis l'interface web .... )

Voila une solution simple, incrémentale et que je n'ai pas trouvé en interface web du syno ...
Après, on peu jouer comme un fou avec ... ( monter du NFS ou de l'AFP par exemple ??? Pour tester les perfs ) .. A vous de voir .

NB - Attention, après un Update du DSM, vérifier qu'il ne remette pas son crontab de Base ( Mais comme toute sauvegarde, même automatisée, on checke de temps à autre que ça se passe bien .. )

mardi 21 avril 2015

ISIS Alternative - INDIESTOR


Indiestor est une alternative sympathique à l'ISIS (mais ce n'est pas un Isis, quoique) Petite Install Rapide & premiers Tests - ( http://indiestor.com ).
L'intérêt de la solution est de recycler une vieille ou petite machine en serveur de projets partagés pour Media-composer et ça fonctionne !!!
La base pour démarrer Indiestor : Installer une Debian ( https://www.debian.org ), faire un user, le mettre ds les sudoers ( Groupe administrator : $sudo usermod -aG sudo <username> ) ou


ZFS
Ca faisait longtemps que je voulais jouer avec donc on installe pour tester ZFS dessus car si l'on a pas un RAID Hardware, ça en fera un soft, mais même avec un Raid-H on peut mettre zfs pour avoir les quotas de indiestor-pro qui ne sont gérés que sur zfs :
http://zfsonlinux.org/debian.html
Là c'est un peu la plaie à installer mais à force ça passe
Après il faut aller lire ça ( globalement y'a tous les cas possible ) : https://pthree.org/2012/12/10/zfs-administration-part-v-exporting-and-importing- zpools/
A savoir :
On peut faire du ZFS de 1 à X Disk, le buter, l'exporter, le ré-importer etc, etc ( ça fonctionne aussi sur OSX : https://openzfsonosx.org, mais pour Windows j'ai pas trouvé ), il n'y a pas besoin de faire fsck dessus, en fait c'est l'ami de l'homme qui est ami avec la ligne de commande un peu quand même .
Base :
- buter les partitions des disques ( zfs fonctionne mieux au Disque qu'a la partoche donc on mettra les disk ds le pool )
- utiliser fdisk et faire juste une partition gpt sur les disques
- faire un zpool :
RAID0 ( ça vaut pour un disque seul aussi )
# zpool create tank sde sdf sdg sdh et ++++
RAID1
# zpool create tank mirror sde sdf
RAID10 ( 1 + 0 )
# zpool create tank mirror sde sdf mirror sdg sdh
RAID5
# zpool create tank raidz1 sde sdf sdg
RAID6
# zpool create tank raidz1 sde sdf sdg sdh
RAID + que 6 ( genre 3 disk de parité )
# zpool create tank raidz3 sde sdf sdg sdh sdi

Après on mixe le tout si on veut après avoir bien lu la doc pour faire du cache, mixer les pools les un sur les autres, faire des snapshots, du cache ...... Si vous vous ennuyez y'a moyen de passer la nuit à jouer avec :

avoir le statut d'un pool
# zpool status tank
dégommer un zpool
# zpool destroy tank
Exporter un pool
# zpool export tank
Importer un pool
# zpool import tank
récupérer un pool
- d'abord pour voir
# zpool import -D
là il va raconter ce qu'il voit ( un peu comme status ) puis ( par le nom ou l'ID ):
# zpool import -D tank
ou
# zpool import -D 17105118590326096187

Tadada -

Là on installe indiestor :
Le pas à pas ( je vais pas le refaire .... ) : http://indiestor.com/install-free/

& les petits plus ( Merci à Fred.S & Alex Gardiner de indiestor .... )
Installer netatalk 3.1.7 ( le paquet debian est un peu vieux )
# wget -q -O - http://free.indiestor.com/indiestor- free.gpg.key | sudo apt-key add -
# echo "deb http://free.indiestor.com/apt/debian wheezy main" | sudo tee -a /etc/apt/sources.list.d/indiestor-free.com.list 
# sudo apt-get update
# sudo apt-get install netatalk
check version:
# dpkg -s netatalk

Un petit Tuning du Pool ZFS :
Be sure to align the ashift value for your drives appropriately. The value should probably be 12, but you can read about that at: http://zfsonlinux.org/faq.html#PerformanceConsideration
& après avoir fait le pool :
Before loading anything into the pool:
# zfs set xattr=sa name_of_pool
# zfs set atime=off name_of_pool
# zfs set sync=disabled name_of_pool

Finally I tend to disable prefetch, as it can cause latency issues with streaming workloads.
# echo 1 > /sys/module/zfs/parameters/zfs_prefetch_disable
To make this change persistant you need to create a config file here, with the following option:
# pico /etc/modprobe.d/zfs.conf
# options zfs zfs_prefetch_disable=1

Après cette première Partie # apt-get update & # apt-get upgrade, on a pas peur, un petit reboot de propreté pour finir et être sur que le Zpool remonte bien aussi ( on colle un dossier test dedans avant ... )
Si tout roule, on peu commencer à Jouer ..

Exploitation INDIESTOR
Sur l'indieServer on fait les Users et les Shares ( avec la GUI sur la Vs Free, mais il n'y a que 2 partages un simple avid-workspace et un public share dans un /indiestore-free. Sur la version Pro on peut faire autant de workspace que l'on veut & utiliser les quotas, mais la GUI n'est pas finie ).

ATTENTION, un truc qui n'est vraiment pas cool : Effacer le user qui crée le projet enlève le projet & les medias du workspace ( le .avid ou .shared !!!! ), donc il faut faire très gaffe avec les projets des users.

Pour finir sur les clients on tune aussi :
http://indiestor.com/avid-afp-tuner/
( ça règle les pbs :“project settings is not saved” (.avp will now save)“Exception: Resource temporarily unavailable” (.avp will not become stuck open) ) & sur PC
http://preptools.net ( ça tune aussi .. )

Pour monter le share de l'indie server sur les clients :
Mac: Cmd + K > afp://IP-OF-THE-SERVER/
Win: users can browse the server for shares and map drives by letter

Le véritable boulot : les projets Avid

Sur un ISIS ( Merci Guillaume !! )
Au niveau de l'ISIS on fait les users, les workspaces, les partages, blabla, les quotas, on met le clientISIS sur les MediaComp ( On ouvre automatique & on monte son workspace ). On crée ou copie un projet & une fois le projet ouvert, on bosse :
Le bin Blockbuster du projet Blockbuster-Cutter est ouvert en edit 1, il a la main dessus, le petit cadenas est vert, edit1 est ROOT dessus, il peut tout faire .


Quand le meme bin du projet est ouvert en edit 2, il voit la même chose, mais le petit cadenas est rouge, il peut piocher ce qu'il veut, mais s'il modifie quelque chose et qu'il veut refermer ce bin, au moment de le fermer, le Media Comp va lui proposer 2 choix :
- soit il sauve le bin sous un autre nom
- soit le bin n'est pas sauvé.
A noter que le bin ne s'update pas automatiquement si edit 1 fait une modif.
Il faut fermer et re-ouvrir le bin sur edit2 pour que celui ci voit les modifs.


De plus, avec un ISIS ( le stockage partagé avid trademark ) et un projet avid dessus :
- Dans le même projet, tu vois qui a ouvert les bins en premier.
Sur ma machine edit 2, je vois que edit 1 a ouvert le bin et le bin est en gras.

Bon alors evidemment :
- Parfois il arrive que meme si edit 1 a fermé le bin, il apparaisse toujours en gras sur edit 2.
Sinon c'est du bug référencé & ça sera corrigé dans la prochaine release mon bon monsieur .....
Le support est pas cher et les équipes sympa ;o)

Sur INDIESTOR
C'est à première vue moins souple ( enfin, c'est surtout pas comme ça fait 10 ans qu'on fait !!! comme openoffice c'est pas excel passque le bouton est pas à la même place !!!!! )

Une fois le workspace monté par le réseau et avoir fait un petit coup de console dans le mediacomp pour avoir alldisks en ecriture ( Commande AllDrives !!! ) si on veut mettre les medias file dessus.

Préambule !!!!
- Indiestor ne tente pas d'imiter directement le partage de projet d'Avid à base de lockfile & du petit cadenas, il ne ressemble pas en ce sens aux solutions comme Editshare, trucmuchshare etc, etc ....
- Pour déclencher le projet partagé , une Station Mediacomp doit tout simplement nommer le nouveau projet ( ou renommer un projet existant ) en : <nom du
projet> .avid
- Indiestor ne check que la racine de chaque workspace. Les Projets dans les sous-dossiers même en .avid ne seront pas partagés .

Exemple :
Les Users edit1, edit2 & edit3 partagent un workspace “base”. Quand il se connectent au storage, chaque user est filtré dans sont propre workspace ( qui est en fait un sous-dossier edit1,2 ou 3 sur le serveur debian mais c'est transparent coté clients ).
Edit1 crée un nouveau shared project a la racine du partage base_avid: /base_avid/testproject.avid/
dès qu'il détecte le .avid indiestor crée une copie .copy du projet pour edit2 et edit3. /base_avid/Avid Shared Projects/testproject.copy/ sur les espaces monté base_avid de edit2 et edit3
( Ok ds mes captures C'est blockbuster.avid et documentary_avid mais l'ID est Là ) 

Je suis edit1 :


Voila ce que voit edit2 dans son Workspace :


Le projet ouvert sur edit1 :


Le projet ouvert sur edit2 ( noter le .avid est un .copy sur edit2 ) :


Quel est le process sur le Travail :
- A la racine du projet les bins ne sont visibles que par leurs propriétaires ( edit1, 2 ou 3 )
- Dans Shared & ses sous-dossiers les bins sont visibles par tous mais éditable que par leurs propriétaires s'ils sont dans le dossier portant leur noms .
- Dans unprotected, on peut travailler tous dans les bins ( a Eviter ), ce dossier sert surtout pour se donner les bins car tous les users y ont accès en lecture/ecriture.

Bon Alors c'est juste des projets autonomes ?
De base, oui, mais reliés entre eux :
Même si chaque projet a ses propres ressources ( .avp , .avs , SearchDB etc ) les dossiers Shared avec les users sont générés automatiquement dans le projet suivant les users qui peuvent être fait à la volée & sont updatés & répliqués dans tous les projets .copy.

Ce partage est simple et il relie les projets ensembles, les updates sans manipulation des users.

Ainsi, en faisant simplement glisser un bin dans le Shared , il devient disponible dans les Projets de tous les users (en lecture seule suivant les dossiers ) .

Dans le Workspace le dossier AvidMediaFiles à la racine est commun.

Evidemment, il n'y a pas le petit cadenas !!!! Oulalalala : Drame ..

L'intérêt que j'y vois ( Hors le coût pour du projets partagés sous Avid!!! ) :
On peut tout à fait imaginer @ l'usage sur un projet un set d'utilisateurs par rapport aux métiers ( RUSHS - SYNCHRO - AUDIO - SYNTé ... etc, etc )
& un Set de monteurs ( A/B/C ..... )
Comme ça personne se marche sur les pieds & chacun fait son taff, ça ressemble de plus beaucoup à la manière de travail en coopération des monteurs sous Avid !!!
Je rajouterais tout de même un Admin qui démarre le projet & fait la maintenance comme ça personne ne risque de Buter le projet source en .avid ( qui effacerait les .copy dans le workspace des autres users )

Sinon pour bien comprendre :
http://indiestor.com/wp-content/uploads/2015/04/ AvidArchitectureExtendedTechnicalNotes.pdf ( qui explique bien comment ça fonctionne ) http://indiestor.com/wp-content/uploads/2015/04/IndiestorWindowsTuningGuide.pdf
La différence entre indiestor free & pro est que sur la vs pro on fait autant de workspace qu'on veut et il y a les quotas !

Petit Plus ( Mes bonnes Pratiques !! )
Déjà on clone le serveur une fois qu'il est fini ( un DD ça coute rien ... & après on peu recoller ça sur un PC même crouteux & ça fonctionne !! ) : http://clonezilla.org ( clef USB / démarrage/option de base -> Clone ) si l'original crash on a un Spare pour changer le système ou juste le stockage de place direct . Pour le stockage en ZFS on fait un export du pool car c'est écrit à la racine de ZFS & c'est plus facile pour un import sur un autre système .

Une soluce de backup est proposé sur le site indiestor ( je suis pas fan, je le trouve un peu compliqué, mais y'a moyen de le scripter pour le faire plutôt en local sur le serveur Indiestor ou de monter un point de partage d'un volume réseau automatiquement au démarrage du serveur et de faire le backup dessus, avantage du clonage documenté chez indiestor c'est que c'est du rsync ) : http://indiestor.com/how-to-backup-your-indiestor-server/

Sinon, à la place en local ou sur un point de partage :
Le petit script de backup ( c'est un cp, alors on ne copie que les projets & on imagine avoir les medias en backup ailleurs évidemment ( C un peu la base d'une bonne pratique, non ?? ) ) :
- A faire sur le serveur

#!/bin/bash
# Dump du projet avec DATE
cp -fR /tank/"nom de l'avid-workspace/Projet.avid" /Emplacement du backup/"Projet.avid".`date +%Y-%m-%d`
# Compression Effacement
cd /Emplacement du backup/
tar -cf "Projet.avid".`date +%Y-%m-%d`.tar "Projet.avid".`date +%Y-%m-%d`/
gzip "Projet.avid".`date +%Y-%m-%d`.tar
rm -fR "Projet.avid".`date +%Y-%m-%d`/
# Effacement des Fichiers de plus de 5 Jours
find /Emplacement du backup/ -type f -mtime +4 | xargs -r rm

Mettre Le script ds le CRON ( sous root ) #crontab -e
Backup à 1H am everyday:
0 1 * * * /path/to/backscript.sh

Voila, voila
c'est un peu partisan bien sur
Mais comme promouvoir FCP7 et decklink à l'époque ... hein !!!
J'èspère que ça vous a plu ( Dzlé pr les fautes, l'autocorrection tue ..... )

PS : Une considération sur le Prix
- Pour Tester : Un NUC i3, La ouache de RAM si ZFS, une tour Raid5 USB3 8To Utiles : 650 / 700 € Max, c'est jouable .
- En Prod : Un Shuttle avec SSD, RAM et Carte 10Gb, une tour Raid5 USB3 8To Utiles, Un Switch 10Gb/24 x 1Gb ( la tour USB3 sera le goulet d'etranglement ) : 2000 / 2500 € Max, ça doit être jouable en cherchant les prix .

& Sinon, un vieux PC de calcul qui ne sert plus avec un RAID0 en interne avec des vieux disques, ça fonctionne aussi ( c'est l'avantage de Linux ..... )

mercredi 4 mars 2015

PIMP my Script ( osX )


Le terminal, c'est assez Génial, on le dégaine, on tape sa petite ligne et poum après 2 ou 3 planages, une relecture : ça marche ….. Yessssss !!!! Mais bon c'est pas super sexy, & puis y'a plein de gens qui veulent pas le dégainer : Ou le vilain truc à la MS-DOS, c'est pas moderne ça monsieur, on a fait des jolis trucs avec bouton depuis les années 20 ( je vous raconte pas mes gosses, si y'a pas un système de briques Lego pour programmer, c'est déja trop dur !! ) .
Okok pour faire plus sexy, on met tout ça dans un script bash, genre #bin/bash avec la ligne de commande à la suite, on enregistre en monscript.sh ( on peu alors le mettre dans un cron ou les launchdaemons personne ne voit rien, impec ), et si c'est pas un truc a automatiser on va chercher Platypus & on recarrosse le .sh sous forme d'une belle App avec un joli nom et une jolie icône, ha ben c'est mieux ça mahame Michu, une App, un gros bouton on appuie & ça fonctionne = tiptop .
Ca reste quand même un script monolithique, et pour les interactions nada, faut tout mettre dans le .sh et l'adapter machines par machines, c'est mieux, ok, mais pas encore topmoumoute . Comment donc faire une jolie fenêtre avec des trucs à cocher ou à choisir qui pourraient interagir avec notre script ?? Ben, tu fais de l'automator ( j'ai essayé, c'est un peu limite qd même … ) ou de l'applescript ( boeurk …) . Alors si vous avez pas envie de vous casser a apprendre un truc compliqué, j'ai trouvé qque chose de 'terrible' : Pashua .
Alors là, c'est l'ami de l'Homme : Tour du proprio .

Pashua va nous permettre de construire des fenêtres, en utilisant les entrées d'interface graphique plus courantes ( Boutons, liste, menu, texte, sélection de fichier ou autre ). Cherchez pas, si vous cliquez sur Pashua l'app directement vous aurez un beau message d'erreur qui vous dira : c'est pas comme ça = va voir la doc, guy !! L'idéal dans un premier temps est de glisser Pashua dans les Applications & de renseigner l'emplacement du binaire ( Pashua.app/Contents/MacOS/ Pashua ) dans votre $PATH le binaire de Pashua .
Lancez votre éditeur de texte favori et entrez ceci:

uname.type = textfield
uname.label = Entrez l'ID utilisateur
uname.default = ID de l'utilisateur
uname.width = 340

Enregistrez : test.sh . Cela indique à Pashua qu'on veux créer un nouvel élément nommé "uname". Cet élément "uname" sera un champ de texte. Il aura un titre au-dessus du champ de texte qui dit: "Entrez l'ID de l'utilisateur", aura comme texte "ID de l'utilisateur". Et le champ sera de 340 pixels. Pour l'exécuter, avec votre Pashua dans le $PATH, tapez simplement:
  Pashua test.sh
( Ou /Applications/Pashua/Pashua.app/Contents/MacOS/Pashua test.sh  si pas dans le $PATH )
& tada :
Appuyez sur la touche de retour, ou cliquez sur le bouton "OK". Voila ce qui se passe dans le Terminal :
  $ Pashua test.sh 
 uname = ID de l'utilisateur
Pashua prend la valeur de l'élément et les envoie sur la sortie standard. Pour un shell, c'est assez génial! Entrée standard vers sortie standard, yessssssss .
Je passe rapide sur tout ce que l'on peut faire dans le script Pashua :
La Cosmétique :
- Régler la transparence de la fenêtre.
- Régler un Autoclosetime pour fermer la fenêtre sans entrée.
- X ou Y pour la position de la fenêtre ( Et des éléments )
- Un titre de fenêtre
Le Pratique :
- Créer un élement type: button
- Créer un élement type: cancelbutton
- Créer un élement type: checkbox
- Créer un élement type: combobox
- Créer un élement type: date
- Créer un élement type: defaultbutton
- Créer un élement type: image Purement Cosmétique
- Créer un élement type: openbrowser
- Créer un élement type: password
- Créer un élement type: popup
- Créer un élement type: radiobutton
- Créer un élement type: savebrowser
- Créer un élement type: text sans Entrée/Sortie
- Créer un élement type: textbox
- Créer un élement type: textfield
Vous pouvez en faire autant que vous voulez, il faut juste que le nom devant .type soit différent .

C'est bien pour l'affichage sur la sortie standard des éléments, mais ça ne nous aide pas trop dans un script. Pour gérer ça, sur le site original ou j'ai pompé l'Article en Anglais ( Credit Machtech ) il y a un script tout fait que j'ai rebricolé ( C un peu crade, j'en conviens, j'étais un peu pressé, sinon il y a aussi des exemples fournis avec Pashua ) :

#!/usr/bin/env bash
result=`/Applications/Pashua/Pashua.app/Contents/MacOS/Pashua $1 | sed 's/ /;;;/g'`
# Parse result
for line in $result
do
        key=`echo $line | sed 's/^\([^=]*\)=.*$/\1/'`
        value=`echo $line | sed 's/^[^=]*=\(.*\)$/\1/' | sed 's/;;;/ /g'`
        varname=$key
        varvalue="$value"
        eval $varname='$varvalue'

done

Enregistrons le script en wrapper.sh, et rappelons comme ça, avec la fenêtre Pashua de notre test.sh:
  ./wrapper.sh test.sh
Entrez des données et cliquez sur "OK". Qué passa ? Apparemment rien. Pas de sortie standard depuis Pashua. Mais en fait le script wrapper à capturé la sortie de Pashua ( & aussi renseigné l'emplacement de Pashua ( Impératif cf Docs avec Pashua ) en l'attribuant à des variables dans le script. Ces variables sont maintenant disponibles pour nous directement. Maintenant, la valeur de retour de uname est disponible dans "$ uname". C'est un script d'emballage !!! 
A ce Stade, en jouant avec Pashua test.sh pour fabriquer & connaitre nos valeurs de sortie std, il ne reste plus qu'a rajouter par exemple à la fin du fichier wrapper.sh

# Mon Script à Moi
rsync --recursive --verbose --perms --executability --acls --xattrs --owner --group --times --progress "$source" "$target"

Pour cet exemple une fenêtre Pashua avec 2 x openbrowser ( renvoyant une sortie source et target / source.type et target.type de type openbrowser dans le script Pashua ) lancerons un Rsync avec les options spécifiées .... C Cool non ????
Alors pour avoir plein de scripts en une ligne, allez faire un tour sur  CommandlineFu .

Et pour aller plus loin, on peut envisager de :
A - Faire une app avec platypus contenant la commande :
cd /Emplacement de Mes Scripts
./wrapper.sh test.sh



B - Dans l'App faite avec platypus Rajouter un Dossier VRAC & mettre nos scripts dedans
En supposant que l'Appli soit obligatoirement dans /Applications refaire le cd /Emplacement du Script ( qui est dans /Applications/MonAppli.app/Resources/script ) et le remplacer par cd /Applications/MonAppli.app/Resources/VRAC qui contient nos 2 scripts test et wrapper.
C - Profitons-en carrément pour mettre Pashua.app dedans aussi et renseigner son chemin dans le wrapper, puis une image si on utilise un image dans test.sh & parce que pourquoi s'arrêter en si bon chemin un dossier bin si j'utilise des binaires folkloriques ....
Voila, voila une app avec Fenêtre qui lance un Script vite fait & transportable facilement sur n'importe quelle machine pour peu que l'Appli soi bien dans /Applications ( en .dmg fait avec keka par exemple ou mieux car plus classe Dmgcreator  )


Un exemple simple mais concret de ce que vous pouvez faire avec Pashua . Mais en premier c'est mieux de lire aussi la documentation fournie, c'est assez rapide. Dans le dossier des exemples, vous trouverez un dossier qui montre comment créer directement une application double-cliquable, mais j'aime bien platypus . Et si vous aimez pas le bash, vu que Pashua accepte un fichier texte en entrée, et envoie sa sortie via la sortie standard. Ca doit fonctionner avec tout langage de script - AppleScript, Bash, Perl, PHP, Python 2, Rexx, Ruby, Tcl . Plus d'infos à jour Là : GitHub







mardi 3 mars 2015

Et les autres OS ???



Evidemment, usage oblige, j'en ai moins, mais il y a aussi les PCs ( pas que les Hackintoshs ) :
Alors en plus des livesCD a avoir dans sa trousse : http://livecdlist.com
Une fois les OS Installés :
- Sur Linux, c'est plutôt de la ligne de commande qu'il faudra jouer mais il y a quand même Framapack qui est assez sympa ( Autres équivalent Ninite sur Win&Linux, GetMacApp et MacApps sur osX ).
- Sur Windows, j'installe souvent directement Liberkey ( la totale ) et je garde toujours un HirenBootCD ou un Falcon4 & un Ultimate sous la main . Sinon je cherche un service + windows app sur Google, c'est comme ça que j'ai trouvé VirtualClone, XXclone,  ShadowImage et NetProfile .
Après c'est souvent au coup par coup .
Sinon sur Alternative.to on peut chercher facilement les équivalents d'un Soft et Filtrer les résultats par PlateForme ou Freeware, ça peut servir !!

mardi 17 février 2015

Trousse Utilitaires osX


Quel utilitaires rajouter à osX ???

Une Liste minimaliste non exhaustive :

- Un bon Wrapper pour lancer des Applis Windows : http://wineskin.urgesoftware.com/tiki-index.php
- Une Interface graphique pour la gestion des droits : http://www.lagentesoft.com/batchmod/
- Un meilleur client VNC : http://sourceforge.net/projects/cotvnc/
- Un meilleur Logiciel pour Find, EasyFind : http://www.devontechnologies.com/products/freeware.html
- GasMask : http://clockwise.ee
- Grand Perspective : http://grandperspectiv.sourceforge.net
- Onyx : http://www.titanium.free.fr/forums/download.php
- Rname : http://www.jacek-dom.net/software/R-Name/
- Sync2Folders : http://throb.pagesperso-orange.fr/site/ind_JS.html?Prg_S.html&Prg_AutresRB.html#SyncTwoFolders
- Xquartz : http://xquartz.macosforge.org/landing/
- TrueCrypt ( Gaffe !! Surtout pas la dernière Version 7.2 ) : https://truecrypt.ch/downloads/ https://download.truecrypt.ch/older/
- Tunnelblik : https://code.google.com/p/tunnelblick/
- UnrarX : http://www.unrarx.com
- Teamviewer port : http://www.teamviewer.com/fr/
- TCP Block : http://www.macupdate.com/app/mac/35914/tcpblock
- CHM View : http://code.google.com/p/ichm/
- Keka : http://www.kekaosx.com/fr/
- Cord : http://cord.sourceforge.net
- QuickLookPlugins : http://www.quicklookplugins.com
- ReducePdf Size : http://proofgroup.com/blog/2012/jun/reducing_the_size_of_pdfs_from_preview
- Macsudoer : https://bogner.sh/2013/01/os-x-macsudoer-and-3-other-ways-to-run-applications-as-root/
- DupeGuru : http://www.hardcoded.net/dupeguru/

mercredi 11 février 2015

Pourquoi BLOGGER.COM ?


- Pour ne pas blogger comme un Pro ( Je ne suis pas dans la monétisation, là ).
- Pour faire avec un truc simple, bien propulsé.
- Pour pas passer 3H à batailler avec du HTML5.
- Pour ne pas hérberger chez moi.
- Pour sa sauvegarde automatique des textes, les plug-ins, une relative bonne gestion des flux RSS…
- Parce que ça ne coute pas un Rond ( Quand c'est gratuit, c'est toi le produit ... ).