mardi 13 décembre 2011

Backups

Aujourd'hui j'ai mis en place plusieurs scripts pour réaliser les backups de ma base de données Cirrus_DB et l'ensemble des cripts disponible dans /home/dev/workspace/METEO.
L'objectif est de réaliser des sauvegardes journalière pour éviter de tomber dans des situations trop frustrantes.

Pour ce faire j'ai croné deux script disponible sous /home/dev/workspace/shell, nommés respectivement :
- backupMeteoScripts.sh
- backupMySQL.sh

Ces scripts ne prenne pas de paramètres en entrée mais corresponde plutot à un contournement de la commande date +"%Y%m%d" utilisé dans mes tables de cron. Effet le charactère % pose des problémes. J'ai eu beau essayé de le forcé avec backslash, rien à faire... L'output que j'obtiens ne me convient pas car intègre justement des backslashs. Plutot que de me casser la tete, j'ai préféré un appel à un script.

J'ai aussi rajouter deux commandes find ne listant que des fichiers ayant plus de 15 jours. Chaque entrée est alors supprimée. De cette façon, j'évite d'avoir 15'000 backups et manger tout l'espace disque avec des tar.gz de sauvegarde,

L'ensemble des jobs est programmé journalièrement aux alentours de 23~23h30.
Les cron ont été réalisé dans l'interface graphine Gnome Cron disponible sur le desktop du user dev.

mardi 1 novembre 2011

Bolam World

Suite à quelques navigations sur le Net, j'ai trouvé plus de cartes BOLAM, notament pour couvrir la partie US, ce qui fournit de précieuses info sur les déprétions à venir si l'on tient compte des jet stream.

Plus de matière sur : http://www.meteochat.it/mappe-globo

dimanche 23 octobre 2011

Austin 23. 10. 2011

Aujourd'hui je vais vous parler du temps à Austin. J'ai l'occasion de cette semaine de me déplacer au Texas et de pouvoir observer la météo en ce lieu.  Les premières observations que j'ai pu réaliser sont avant tout un grand ciel bleu. Les températures observées avoisinent les 20 degrés. l'air est globalement sec. Je n'observe aucune formation nuageuse dans le ciel. Je n'ai pour l'instant pas eu l'occasion de pouvoir voir des cartes météo. Je corrigerai ce manque d'observation au cours de l'après-midi. Pour le moment je vais aller dehors et compléter mes observations de visu. Par la même occasion je vais en profiter pour aller manger un steak  texan ! bon appétit!

jeudi 13 octobre 2011

Monter un FS Windows sous une VM Linux

Petit trics pour monter rapidement des FS Windows sous Linux.
Cela me simplifie la vie et me permet de sauver les images video sur un disk USB gérer sous WIN 7. J'accède via la VM Fedora 14 Cirrus. Sorry, mais je la joue en Anglais cette fois...

List available shares places

smblient -L velocitor -U denis

Mount a drive from Windows

Based on use of mount.cifs
You must install first cifs-util package

mount -t cifs -o user=denis,password=Souris2007,uid=dev,gid=users //velocitor/meteo /mnt/METEO

umount / mnt/METEO

FSTAB definition

//velocitor/meteo /mnt/METEO cifs username=denis,password=Souris2007,uid=dev,gid=users,_netdev 0 0

vendredi 16 septembre 2011

Mieux et plus simple

Mieux et plus simple... C'est un peu la conclusion de ce message aujourd'hui.
Après quelques inquisitions du coté de wetter3, je me suis rendu compte que les archives sont accessibles online. Ok, sentiment mitigé! C'était tellement mal mis en valeur dans le site que je suis bien passé à coté! Il existe en fait sur www2.wetter3.de/Archiv/GFS un repertoire d'archivage des images générées tous les jours par le modèle. La convention d'organisation consiste à nommer le fichier image de la façon suivante :

YYYMMDDHH_IDX.gif


  • YYYY Année cherchée
  • MM Mois cherché
  • DDJour cherché
  • HH Heure cherchée

Conclusion : je vais réécrire mon joli script de download. J'ai d'abord ressenti une certaine frustration à cette idée. Ais je perdu mon temps pendant une semaine ? Je pense que non pour deux raisons :
Intérêt technique du développement. Celui ci ma permit de me familiariser avec les appels SQL en Perl et les manipulations de date.
Intérêt fonctionnel : Le nouveau script permettra de contourner l'écueil de date de calcul que je rencontrai jusqu'à maintenant. Je vais effet à la pêche sur le répertoire courant de simulation pour le moment. Wetter3 garde en actif 4 relevés (24h00) dispo en ligne sur la page de visualisation courante . J'ai du mal à estimé quand le switch se fait d'un relevé à l'autre.

Pour l'occasion je vais backupé la version actuelle de mon script getMeteoMaps.pl et faire une réécriture de la logique. En effet pas mal de fonction écrite avant vont me permettre d'avancer plus vite dans le développement je l'espère.

Et hop... Un petit tour du code.
En fait les modifications sont très limité. J'ai changé le lien de référence hardcodé par défaut. J'ai adapté ensuite le pattern de découpage porté par le nom de la ressource à downloader. Le script marche du premier coup...

Ok, une petite modification à prendre en compte cependant. Pour le moment les download se font sur la date du jour. Il faut mettre en place une nouvelle boucle pour parser des intervalles de dates donnés via la ligne de commande.
Pas compliqué ;)

jeudi 15 septembre 2011

getMeteoMaps.pl : Synchro des downloads wetter3

J'écris en ce moment un programme (getMeteoMaps.pl) pour procéder aux downloads d'images depuis le site wetter3. 

En faisant des tests de mon script, je me rends compte que les images sont mise à jour en temps réel avec l'unité de simulation. Cela s'observe par le fait que je tombe régulièrement sur des pages "vides" et qui du moins sont en cours de download. 
J'en conclu pour le moment que le temps de calcul doit s'étaler à partir de l'image de référence t + 00. 

Afin de cadrer l’exécution de mes jobs, je dois connaitre les heures de démarrage de calcul du modèle et la durée des traitements. Cela me permettrai de prendre un peu de marge de manœuvre et de "croner" le démarrage du script au bon moment (quand toutes les images sont la).

Pour l'instant je fais une approximation de l'heure de calcule entre 00, 06, 12 et 18. Pour cela je fais des comparaisons avec ces références. Si ma ref estimée est plus grande que la valeur alors je prend celle ci comme référence. Si ma ref est plus petite, je prends l'estimation 6 heure avant. Le problème c'est que je tombe dans le répertoire en pleine simulation et qu'il manque pas mal d'image selon le moment ou je lance le traitement.

Pour le moment il est 20h00, je remarque que je pèche toujours les prévisions de 12 h 00 en utilisant un browser web. Cela signifie que le run en cours d’exécution est celui de 06h00... Et il n'est pas encore fini. L'idée est donc de déterminer le deta temps de calcul pour le prendre en compte dans ma planification ou directement dans le script.

5 minutes plus tard : Argh... Je regarde mon code... C'est pire que cela... J'ai harcodé la carte de référence sur le repertoire à 00 h.
Donc il faut que j'inclu une logique de calcul pour réaliser le mécanisme décrit ci dessus.

lundi 5 septembre 2011

Extracteur images wetter3.de

Ok, j'ai donc un extracteur de données locales de météo en allant me connecter sur Dayer.biz.

Je souhaite à présent pouvoir corréler ces relevés avec des cartes et analyses disponibles sur le net. Pour cela j'envisage l'utilisation du site wetter3.de. L'avantage du site est la mise à disposition régulière de cartes calculées par un modele de prévisions. Les données sont très complétes et seraient intéressantes à conserver. Plusieurs points cependant :
  • Les cartes seront à conserver sur FS pour ne pas charger la DB
  • Les références de la cartes seront stockées dans la DB cirrus. L'idée est de créer un lien physique sur le fichier image qui correspond sur FS
  • Il existe 34 cartes différentes. Je pense qu'il est nécessaires de gérer une table pour la nomenclature de ces cartes. Cela permettra des sélections précises par la suite. 
  • Les cartes sont accessibles par simple lien HTML, il me faut donc un extracteur pour récupérer ces fichiers
  • Les formats de cartes sont essentiellement du GIF
  • Les cartes sont calculées tous les jours. Les prévisions étant sur trois jours, on risque d'avoir de la redondance dans les cartes stockées. La régle consiste à garder les cartes les plus à jour quitte à écraser d'anciennes version
  • Les cartes seront conservées dans une structure de répertoire faisant ressortir le formalisme "yyyy-mm-dd". On organise les cartes par rapport à la date qu'elle couvre, et non pas en fonction de la date de simulation.
Les accès aux cartes se font sur le lien suivant :
http://www2.wetter3.de/Animation_06_UTC


J'en conclu qu'il existe un batch journalier de simulation pour fournir les cartes UTC 06. Le download devra tenir compte de cette heure (minuit?)
La construction des noms des cartes se fait de la façon suivante :
<time>_<family>.gif
  • <time> représente l'heure de simulation par rapport à la date de référence à l'heure UTC 06. Les prévisions sont faites à 180 heures.
  • <family> est un index qui permet de déterminer à quel type de carte on a affaire.
  • La génération des noms de cartes respecte toujours cette règle et peut de ce fait être automatiser (cela nous évite de coder un crawler / extracteur HTML pour le traitement)
Il faut tenir compte de l'heure de simulation et la date de référence pour pouvoir transmettre les fichiers récupérés dans les bons répertoires de destinations. Cela nécessite de changer le formalisme du nom sur FS pour obtenir une forme du type :
<time>_<family>.gif
Mais ici <time> sera une valeur comprise dans l'interval des valeurs [0,6,12,18], ce qui permet de régler en partie les problémes de doublons lors du download.
L'extracteur sera écrit en Perl. Il doit permettre de :
- Spécifier le lien du site de download
- Spécifier la racine de la structure de stockage
- Gérer la gestion de doublons
- Tenir des journaux à jours pour le suivi des actions et des erreurs
- Le traitement devra impérativement être démarré une fois par jour car wetter3.de ne gère par d'archives!

mardi 30 août 2011

SQL, Schéma de bases

Je suis en train de me former sur le language SQL et j'ai commencé quelques réflexions concernant le design de la base de  données de Cirrus. Il en ressort un certain nombre de point à approfondir.

Harvesters

Tout d'abord quel schéma de bases de données je souhaite utilise?. Pour le moment mes efforts se sont focalisés sur l'acquisition des données depuis dayer.biz. En est ressortie un "Harvester" qui me permet de récupérer régulièrement les données de ce site. Le programme est opérationnel et permet de downloader les données de bases qui vont populer mon schéma. Cela représente pour le moment environ 40'000 record de relevés. La fréquence est de l'ordre de l'heure concernant ces données. Par la suite j'adapterai le programme Perl pour faire l'acquisition de données provenant de ma station météo. Les aménagement à prévoir sont l'acquisition de données CSV plutôt que des pages WEB. Dans l'absolu, je pense que cela devrait simplifier les choses.

Schéma

Mes premières réflexions sur le schéma de base de données à adopter sont orienté sur l'utilisation de table chaînées reflétant des statistiques à des périodes données. Ainsi je distingue cinq tables de bases me permettant de faire des analyses.

  •  weatherData : données brutes. La fréquence est de 60 minutes pour le moment. Pourquoi pas à terme descendre à 15 minutes. La table contient des données de bases comme la pression, température, point de rosé...etc. qui me permettent ensuite une analyse plus fine du temps.
  • dailyStats : Regroupe des statistiques à l'échelle de la journée. Un enregistrement de cette table correspond à des calculs pour une journée donnée. La sélection se fait donc sur la date. A ce sujet, la date doit être marqué comme index pour weatherData.
  • weeklyStats : Regroupe des statistiques à l'échelle de la semaine. Un enregistrement de cette table correspond à des calculs pour une semaine donnée. La sélection se fait donc sur la date. Il faut en déduire le numéro de semaine. A ce sujet, la date doit être marqué comme index pour dailyStats.
  • monthlyStats : Regroupe des statistiques à l'échelle du mois. Un enregistrement de cette table correspond à des calculs pour un mois donnée. La sélection se fait donc sur la date. La date doit être marquée comme index pour weeklyStats.
  • yearlyStats : Regroupe des statistiques à l'échelle de l'année. Un enregistrement de cette table correspond à des calculs pour une année donnée. La sélection se fait donc sur la date. La date doit être marquée comme index pour monthlyStats.

dimanche 14 août 2011

Ajout du point de rosé

Suite à quelques essais sur le calcul du point de rosé, j'ai trouvé une méthode d'approche relativement précise pour mes mesures. Je souhaite donc à présent l'intégrer dans mon schéma de table weatherData.

- L'information est en degrés.
- Le dew point peut etre positif ou negatif
- Les valeurs ne dépasse pas 100 en positif ou en négatif.
- Je souhaite donner une précision à deux chiffres après la virgule

L'ajout de cette information nécessite des modifications au niveau du programme de collecte de données météo "getWeekWeatherTable.pl". Les mises à jour correspondent à une modification du format de sortie pour ajouter la donnée dew point soit au niveau des CSV générés, soit au niveau de la table weatherData.

D'autre part, les valeurs dèjà existantes (environs 40'000) devront intégrées cette nouvelles données. Cela nécessite surement l'écriture d'un programme sur mesure pour modifier les champs existant un à un.

vendredi 12 août 2011

Approximation du point de rosée

Un élément que j'ai oublié dans ma table weatherData, le point de rosée. Voila une approximation possible pour le cacul tiré d'un article wikipedia : http://en.wikipedia.org/wiki/Dew_point

Une approximation bien connue utilisée pour calculer le point de rosée Td étant donné l'humidité relative HR et la température T réelle de l'air est:


T_d = \frac {b\ \gamma(T,RH)} {a - \gamma(T,RH)}
where

\gamma(T,RH) = \frac {a\ T} {b+T} + \ln (RH/100)
où les températures sont en degrés Celsius et «ln» désigne le logarithme naturelLes constantes sont les suivantes:
a = 17.271
b = 237.7 °C
Cette expression est basée sur l'approximation août-Roche-Magnus pour la pression de vapeur saturante de l'eau dans l'air en fonction de la température [3]. Il est considéré comme valable pour : 
0 °C < T < 60 °C
1% < RH < 100%
0 °C < Td < 50 °C
Les données dont je dispose avec les relevé récupéré de dayer.biz sont :
  • La pression
  • La température moyenne pour une heure
  • L'humidité moyenne pour une heure
Je pense que la température relevé par le thermometre est la temperature seche.L'humidité relative est probablement celle affichée sur ma station, mais il faut que je m'en assure. Pour dayer, je ne sais pas trop comment vérifier. A noter qu'il serait bon de reprendre cette information et de la rajouter à la définition de la table weatherData. L'information du point de rosée permettrait notamment de déduire la haute du plafond nuageux. Cette valeur restera evidement approximative mais permet de donner une idée plus précise des conditions nuageuses.
La méthode d'approximation reste à définir pour un prochain article.

jeudi 11 août 2011

Extract des données Dayer.biz par semaine

Ok, plutot que d'écrire from scratch un programme de génération de données météo, j'ai décidé de me remmettre au travail sur l'ecriture d'extracteurs WEB de données en provenance du site dayer.biz.

Je vois plusieurs avantage à faire cela :
  • L'écriture d'un programme de génération de données météo valable est un sujet intéressant mais complexe. L'écriture du programme risque de me prendre plus de temps que je ne souhaite y consacré.
  • Je devrais de toute façon récupérer un jour ou l'autre les données existantes de dayer.biz pour populer ma base météo
Cependant il existent des désavantages à faire cela :
  • La périodicité des données est de l'ordre de l'heure, donc la fréquence des relevés données sont en dessous de ce que j'avais prévu comme base soit 15 minutes.
  • Je garderais 15 minutes comme délai de récolte pour ma station
  • Il va falloir prendre en compte le fait que je travail également avec des données sur une heure plutôt que quinze minutes 
Le programme de récolte écrit s'appel "getWeekWeatherTable.pl"
Il est écrit en PERL, lequel language se prête plutot bien à ce genre d'exercice. Le programme est capable de récupérer au minimum 1 semaines de données. La sortie se fait dans un fichier CSV et/ou directement sur la base SQL.

Il est à noter que j'ai légérement modifié la base de données pour intégrer un champs signature.
Ce champs est un calcul de MD5 sur la date/heure et le lieu. Ce système me permet de faire des contrôle de doublons avant insertion afin de ne pas charger plusieurs fois les mêmes données.
De plus le nouveau schéma utilisé implémente des index sur la signature, la date et la localisation pour améliorer les perfs par la suite.
Le schéma de weatherData est à présent celui décrit ci dessous :

CREATE TABLE `cirrus_db`.`weatherData` (
  `idweatherData` int(11) NOT NULL AUTO_INCREMENT,
  `fingerprint` varchar(45) NOT NULL,
  `date` datetime DEFAULT NULL,
  `idLocation` varchar(64) DEFAULT NULL,
  `temperature` decimal(5,2) DEFAULT NULL,
  `pressure` decimal(6,2) DEFAULT NULL,
  `moisture` decimal(5,2) DEFAULT NULL,
  `wind` decimal(5,2) DEFAULT NULL,
  `winddir` varchar(20) DEFAULT NULL,
  `rain` decimal(5,2) DEFAULT NULL,
  `uv` decimal(4,2) DEFAULT NULL,
  PRIMARY KEY (`idweatherData`),
  KEY `byDate` (`date`) USING BTREE,
  KEY `byLocation` (`idLocation`) USING BTREE,
  KEY `byFingerprint` (`fingerprint`) USING BTREE
) ENGINE=MyISAM AUTO_INCREMENT=200322 DEFAULT CHARSET=utf8 COMMENT='Raw weather info / updated hourly';

jeudi 4 août 2011

Note sur l'utilisation des données UVI de dayer.biz

J'ai la chance d'habiter pas très loin d'un amateur de météo qui a mis une station en ligne avec un micro site de météo. Je dois avouer que je lui pique ses données depuis maintenant trois ans. Déjà, j'aimerai lui dire combien je lui suis reconnaissant d'avoir mis l'ensemble de ces informations en ligne. C'est une vraie mine d'or pour moi tant que ma station météo et mon projet d'automatisation des collectes de mesures soient au point. Un GRAND MERCI dayer.biz!

Il s'impose cependant de faire la remarque suivante concernant les représentation graphique et les calculs de moyenne UVI pour la journée. Les données, malheureusement ne tiennent pas compte du cycle nuit/jour et les moyennes sont caculées sur 24h00 !

Une première correction peut consister en rapportant la moyenne au cycle jour/nuit, soit entre l'heure de levé et celle de couché du soleil. Cette première approximation est surement la meilleure. Elle tient compte d'une moyenne générale de la luminosité sur le temps réel d'exposition au soleil d'une part. D'autre part, cette moyenne est atténuée lorsque l'angle du soleil à l'horizon et faible. J'estime entre 0°C et 20°C matin et idem pour le soir ces périodes transitoires d'exposition. Le fait de prendre en considération ces périodes dans le calcul de la moyenne réduit celle-ci du fait de la faible exposition lors des périodes transitoires. Par contre, elle permet de prendre en compte des situations d'exposition partielles optimales en début et fin de journée, et donc de potentiellement élever la moyenne si le reste de la journée est couverte.

Dans cette idée, on peut aussi remarquer la moyenne est probablement plus "déviante" en été que les autres saisons. Ceci est notamment du à l'angle du plan de l’écliptique avec l'horizon. Cet angle est plus faible pendant ces trois saisons.

L'idée est de rapporter la moyenne sur 24 h 00 à une moyenne sur le temps d'exposition. Les calculs sont une simple règle de trois. On fait ici une extrapolation linéaire. Le calcul est évidement empirique. Il permet d'avoir une approximation à la louche mais quand même un peut plus proche de la réalité.

Méthode de calcul proposée
  • Calculer la différence de temps dt en soustrayant l'heure de coucher à l'heure de levé du soleil. On obtient de cette façon le temps d'exposition. 
  • Diviser la moyenne prise sur dayer.com par 24 
  • Multiplier par le temps d'expositon obtenu dans le premier point


Exemple
 temps expo 14.68
 levé 06:15 
 couché 20:56           

Correction relevé UVI Dayer.biz 
UVI avg 2.8
UVI/hour 0.19  (UVI avg/temps expo)
UVI expo 4.58 (UVI/hour * 24)

Générateur de jeux de test

Suite à la description de la structure weatherData, je souhaite à présent écrire un générateur de données météo pour pouvoir populer cette table. L'objectif est de fournir des données à volonté pour pouvoir ensuite faciliter le développement de fonctions de calcul et de prévision sur le serveur SQL.

Le générateur doit respecter un cahier des charges pour pouvoir fournir des informations pertinentes et propice à l'analyse de données.

Je suis donc devant un nouveau chantier pour réaliser un générateur stochastique de données météos. Mais qu'est ce donc ? Un générateur stochastique de données météorologiques produit, pour un endroit donné, des séries chronologiques artificielles de données météorologiques de longueur illimitée, qui reposent sur les caractéristiques statistiques des conditions observées à cet endroit. Ces types de modèles statistiques sont généralement élaborés en deux étapes, la première consistant à modéliser les précipitations quotidiennes, alors que la deuxième se concentre sur les autres variables d’intérêt, telles que les températures minimales et maximales, le rayonnement solaire, l’humidité et la vitesse du vent, qui sont simulées de manière conditionnelle selon l’occurrence de la précipitation. Pour chaque mois, des paramètres différents sont choisis de façon à refléter les variations saisonnières à la fois de la valeur des variables proprement dites et de leurs corrélations croisées (soit dans les rapports entre les variables individuelles au fil du temps).


Donc la c'est simple : soit je me fait mon propre générateur, au risque d'y passer des heures car je souhaite quelque chose de réaliste, soit je vais voir sur le net ce que je trouve...


Aller, un ptit tour sur un moteur de recherche et je trouve le site suivant :
http://www.rothamsted.bbsrc.ac.uk/mas-models/larswg/download.php

C'est un lien vers un générateur gratuit. Par contre cela n'a pas l'air forcement simple à l'utilisation... Alors je vais faire mes petits essais... We keep in touch.

mercredi 27 juillet 2011

Setup d'un serveur CVS

Tutorial pour la mise en oeuvre d'un serveur CVS


Login as "root":

(1) Get xinetd package installed


(2) Get cvs package installed


(3) Create a group CVS


(4) Create a user cvsroot and assign it to CVS group, the home directory for user cvsroot should now be at /home/cvsroot.


(5) $gedit /etc/services
and look for "cvspserver". There should be 2 lines like:
cvspserver 2401/tcp # CVS client/server operations
cvspserver 2401/udp # CVS client/server operations
If there are no such lines, add them into /etc/services.


(6) In /etc/xinet.d/, look for file "cvs", if there is no such file, create it.
Edit the file /etc/xinet.d/cvs and make it look like:
# default: off
# description: The CVS service can record the history of your source \
# files. CVS stores all the versions of a file in a single \
# file in a clever way that only stores the differences \
# between versions.
service cvspserver
{
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
}

(7) $/etc/init.d/xinetd restart

(8) In "System"->"Administration"->"Security Level and Firewall", add firewall exception of port "2401" corresponding to "cvspserver" service, and also remember to "Modify SELinux policy"->"SELinux Service Protection"->"Disable ELinux Service Protection for cvs".
This step is proved to be very important!

Login as "cvsroot":

(9) $cvs -d /home/cvsroot init

(10) $cd /home/cvsroot

(11) $chmod 771 CVSROOT
CVSROOT is a directory automatically generated under /home/cvsroot.

At this time, all local real system users can log into CVS server with their own passwords.
If you want to disable local real system users' login, you can do by:

(12) $ chmod 644 /home/cvsroot/CVSROOT/config
$ vi $CVSROOT/CVSROOT/config
Here you need to uncomment the line where #SystemAuth = yes. And set SystemAuth = no.

Then now your system users cannot use CVS service with their own system passwords, except you assign them manually in file /home/cvsroot/CVSROOT/passwd.

(13) To control user access in CVS, there are three files in /home/cvsroot/CVSROOT/, respectively named passwd, readers, writers. The file readers and writers are not there by default, so you have to create them manually.

In file "passwd", ithere stores the shadow files for username and password, following the rule:
{cvs usrname}:[encrypted pwd]:[equivalent system usrname]
where the second field is encrypted with crypt(3), just like in /etc/shadow.
The thrid field equivalent system usrname means the corresponding system priviledge the cvs usrname has.

In file "readers", there stores the list of cvs usrnames of whom you want to enable to only have read acess.

Similarly, in file "writers", there stores the list of cvs usrnames of whom you want to enable to only have read acess.

Now, let us suppose we have CVS users "henry", "betty", "anonymous". And we don't want to give them system access, which means the corresponding system priviledge the cvs usrnames have are all null. So, we need to create an equivalent system user, which names "cvspub", who has no system priviledge at all.

$ useradd -g CVS -M -s /sbin/nologin cvspub

Then edit file "passwd", make it like:

henry:$fajkdpaieje:cvspub
betty:fjkal;ffjieinfn/:cvspub
anonymous::cvspub

Now suppose we want to let henry has write acess while betty and anonymous only have read acess.
Then edit file "readers", make it like:
betty
anonymous

And edit file "writers", make it like:
henry

Then it is all finished.

(14) Test login:
$export CVSROOT=:pserver:henry@the_server_name:/home/cvsroot
$ cvs login
(System will ask for password for henry)
Passwd:xxxxxxxx
There should be no error when you have successfully login to the CVS server.


Problem:
cvs [login aborted]: unrecognized auth response from brachial.umn.edu: cvs pserver: cannot open /home/cvsroot/CVSROOT/config: Permission denied

Solution:
In "System"->"Administration"->"Security Level and Firewall", add firewall exception of port "2401" corresponding to "cvspserver" service, and also remember to "Modify SELinux policy"->"SELinux Service Protection"->"Disable ELinux Service Protection for cvs".
This step is proved to be very important!

Problem:
cvs import: cannot open /root/.cvsignore: Permission denied

Solution:
Add "-f" to the arguments for cvs in /etc/xinet.d/cvs:
server_args = -f --allow-root=/home/cvsroot pserver

mardi 26 juillet 2011

Cirrus DB - weatherData table

La base Cirrus est utilisée pour stockée les relevés météo bruts et des résultats statistiques. La base repose sur l'utilisation d'une table "weatherData" destinée au stockage des données brutes. LA clé primaire est l'identifiant unique de l'enregistrement. Cette partie est laisser à la charge du serveur SQL pour générer une clé unique à chaque enregistrement de nouvelles données.

Détail de "weatherData" :

WeatherData est probablement la table la plus importante du système puisqu'elle gérer l'ensemble des relevés bruts. Toutes déductions, statistiques et autres calculs reposent directement ou indirectement sur le contenu de cette table.

L'un des critères clés pour obtenir de l'information depuis cette table consiste à utiliser l'information date. Ce n'est pourtant pas la clé primaire, laquelle repose sur un identifiant unique. Par contre le champ date (qui sera probablement un time stamp) est décrite comme étant un index car celui-ci sera quasi systématiquement sollicité dans des traitements ultérieurs.

L'ID (idLocation) du lieu de la prise du relevé est aussi une clé identifiant qui sera assez souvent solliciter. On tire en effet les statistiques et les prévisions d'un lieu donné dans la plus part des situations. Le champ est donc marqués comme étant un index.

Un champ fingerPrint est disponible en fin d'enregistrement. Ce champs a pour objectif de fournir un moyen de controle pour eviter de capturer des doublons de mesures.

idWeatherData       - identifiant unique enregistrement météo (PRIMARY_KEY)
date                       - time stamp + date (INDEX)
idLocation              - identifiant relevé météo (INDEX)
temperature            - temperature en C°
pression                 - en hPa
moisture                 - en %
wind                      - en km/h
windir                    - String direction
rain                        - tombée de pluie pour l'heure courante
uv                          - indice UVI
fingerPrint              -  Empreinte du relevé pour éviter de créer des doublon (String)

TODO

- Construire un programme de génération de données de tests
- Charger une base

lundi 25 juillet 2011

Before we start...

Peut être quelques mots avant de commencer ce blog. Je suis passionné par ce qui concerne le ciel, son interprétation et faire des prévisions. Cela fait 5 ans que je m'intéresse un peu à la météorologie, mais plus de 37 ans que j'ai la tête dans les nuages. Je suis un amateur, un aimant... Je n'ai pas la prétention de me considérer comme bon sur le sujet, j'ai juste soif d'apprendre... Patiemment.

L'objectif de ce blog est de regrouper un ensemble d'idées et de techniques liées à l'observation du ciel et à leurs interprétations informatiques. Je dispose en effet d'une station météo chez moi et souhaite mettre en place un certain nombre d'outils de mesures statistiques pour aider à la prévision.  Je souhaite automatiser un système de collecte de données et de les stocker en base relationnelle. Ces informations sont ensuite traitées par la suite pour tirer des statistiques ou revenir sur des séquences d'événement ayant eu lieu dans le passé.

Les données publiées ici sont sous forme de notes thématiques sur les différents sujets et disciplines nécessaires à la conception d’outils de collecte / stockage / interprétations de relevés formalisés. Elles peuvent être utilisées par la suite à la volée pour des développements en itérations. Ces idées/notes sont organisées et tagguées pour être facilement consultables.

Ce blog est donc une base de connaissances d'idées brutes, de points à améliorer et de propositions de pistes, de présentation de concepts...

Ne comptez pas sur une qualité orthographique poussée dans la présentation de ce contenu. Ce site est la pour renseigner, et non pour faire honneur à l'art écrit.