observium , serveur de supervision

17 juin 2015

Agent

la base des agent se compose de  l’activation du service snmp que ce soit sur linux ou MS

Pour la config des agents

https://www.abyssproject.net/2014/08/configurer-snmp-observium/

Ou un petit script

https://gist.github.com/d-a-n/11319189#file-observium_agent_setup-sh

 

Autre source

http://www.deldude.com/installation-dun-agent-observium/

 

Extension

Ensuite on ajoute la visu du traffic
http://blog.best-practice.se/2014/07/using-php-weathermap-with-observium.html

 

 

Forcer le chargement d’un fichier de langue

30 juillet 2012

Dans certain cas, il peut être nécessaire de forcer le chargement d’un fichier de langue spécifique;

par exemple, dans un triggers spécifique à un sous module donné, le fichier de langue peut ,ne pas être chargés.
Dans cette hypothèse, le recours existe.. via l’utilisation du constructeur de page.

/// Forcer appel fichier de langue
global $page;
$page->pile_file_lang(DIR_WS_LANGUAGES.$page->page[‘language’].’/modules/account/ac_annonce/ac_annonce.txt’);

note sur la gestio des acl

20 mai 2012

lors de la gestion des utilisateur et des groupes , seul les membre d’un groupe , ou d’un niveau plus haut peuvent modifier et accéder aux membre inférieur.

le groupe numero « 1 » à accès à tout

le niveau le plus important et le niveau 1, le plus faible à le chiffre le plus élevé.

le control des acl contrôle si le niveau du groupe de l’utilisateur courant est inférieur ou égale à l’option / action courante ;

Mise en place de filtre destinés aux listing du backoffice

29 avril 2012

Cette note n’est valable que pour les modules de pages exploitant héritant de la class ModTwo.

A ce titre, la plupart de l’implémentation du filtre à lieux  dans la section GetConf de la classes, et dans la définition de l’ensemble des éléments de la variable $InitInfo.

Pour mettre en oeuvre les filtres, le plus simple à mettre en oeuvre consiste à ajouter le choix des colonnes visibles. A cette fin , le gabarit html est déjà conçu. Il suffit donc de l’initialiser, en fournissant l’ensemble des éléments nécessaire à son initialisation correct.

Dans notre exemple, nous partons dans le contexte que l’action courante est : ‘listing’

Section dans la function GetConf

Dans un premier temps, ajouter une variable dans la class

  /**
    @var array info all tabs for filter listings
  */
  public static $allfields = array();

Puis dans la méthode GetConf, apres les section de definition des var static, et constante JSONSTATMENT, placer la definition de l’ensemble des colonne qui seront disponible pour cette selection.
/**
@remarks this define col theader title, and ajust html code
Just for Edit listing
*/

self::$allfields = array(
	'o.orders_id' => array( 
		'sort'=>true, 
		'text'=>__('orders table heading order id'),
		'width'=>'2%', 
		'class'=>'tcenter',
		'default'=>true,
		), 
                ....
             );

Puis construire le début de la structure des theader ou tfooter et ou modele. Dans notre exemple, nous allons définir 3 colonne supplémentairement qui seront affiché systématiquement. C’est le cas pour les 2 première colonnes, fournissant le bouton plie/déplie du détail, et la colonne pour sélectionner cette ligne. Enfin, nous placeront aussi la colonne action.

/**
	@remarks Construct all list , fields , th/td 
*/
self::$InitInfo['theader']['listing']=array(
		0 =>array('width'=>'2%', 'class'=>'tcenter', 'txt'=>' ' ),
		1 =>array('width'=>'2%', 'class'=>'tcenter', 'txt'=>' ' ),
		);
self::$InitInfo['tfooter']['listing']=self::$InitInfo['theader']['listing'];

self::$InitInfo['modele']['listing']=array(
				0 =>false,
				1 =>false,
	);



self::$InitInfo['modele']['listing']['action']=false;
self::$InitInfo['theader']['listing']['action']= array( 'class'=>'row_action', 'txt'=>__('table heading action') );
self::$InitInfo['tfooter']['listing']['action']= array( 'class'=>'row_action', 'txt'=>__('table heading action') );

Pour ce qui est de la boucle dynamique, nous utiliseront le control sur le tableau de filtre de la session utilisateur.
Dans noter contexte, nous utiliserons une boucle comme suit :

// min  fields and not view directly colonne fields
$listfield = 'o.orders_prefix, s.status_color as orders_status_color,';
// put in 
if(isset($_SESSION['filters'][__CLASS__]['allfields']))
	$_SESSION['filters']['allfields'] = $_SESSION['filters'] [__CLASS__]['allfields'];
else
	$_SESSION['filters']['allfields'] = array();

	$in_session = $_SESSION['filters']['allfields'];
// check and appli
foreach(self::$allfields  as $key=>$row){
	$clean = substr($key, (strpos($key, '.')+1));

	if(is_array($row)){
		$txt = $row['text'];
		$alias = (isset($row['alias'])? $row['alias'] : $clean);
		$css = (isset($row['class'])? $row['class'] : 'tcenter');
		$width = (isset($row['width'])? $row['width'] : '5%');
	}
	else{
		$txt = $row;
		$alias = $clean;
		$css = 'tcenter';
		$width = '5%';
	}

        if(
	( isset($in_session[$clean]) &&  (string)$in_session[$clean] == 'on' )
	|| ( count($in_session) <=1  && ( is_array($row) && isset($row['default']) &&  $row['default'] == true) )
	) {
		$_SESSION['filters']['allfields'][$clean] = 'on';
		/**
			@remarks this define col theader title, and ajust html code
		*/
		self::$InitInfo['theader']['listing'][]= array( 'width'=>$width, 'class'=>$css, 'txt'=>$txt);
		self::$InitInfo['tfooter']['listing'][]= array( 'width'=>$width, 'class'=>$css, 'txt'=>$txt );
		/**
			@remarks this define col in table, and if is possible sort
		*/
		self::$InitInfo['modele']['listing'][$alias]=true;

		if($clean !=$alias)
			$listfield .=$key.' as '.$alias.',';
		else
			$listfield .=$key.',';
	}
	}

 

Puis la transmissions du tableau complet des options de filtre disponible

 self::$InitInfo['allfields']['listing'] = self::$allfields ;

Et pour finir l’activation proprement dite des tabs des filtres

/**
 @remarks Active forms filter
*/
self::$InitInfo['tfilter']['listing']=array(
/* Premier filtre spécifique a cette page */
					array(
					'title'=>__('orders filter tab clause'),
					'content'=>tep_get_include_contents(__CLASS__.'/filter.clause'),
                 			),
/* Second filtre utilisant le ModTwo et le choix des colonnes  */
				array(
					'title'=>__('orders filter tab fields'),
					'type'=>'listfield'
				),
			);

Enfin la transmission des champs a utiliser dans la requetes sql

/**
		@remarks Put detail for listing methode 
	*/
	self::$InitInfo['adjust']['listfields'] = substr($listfield, 0,-1);

Section dans la function check_action

La section de prise en charge du formulaire , dans le switch des actions

/**
	@remarks specific save in session value filters 
*/
case 'filters':
	$_SESSION['filters'][__CLASS__]['allfields'] =array();
	foreach($_POST['allfields'] as $key=>$row){
		if( $row =='on' )
			$_SESSION['filters'][__CLASS__]['allfields'][$key] = 'on';
		else
			unset($_SESSION['filters'][__CLASS__]['allfields'][$key]);
	}

	$_SESSION['filters'][__CLASS__]['viewstatus'] =array();
	foreach($_POST['viewstatus'] as $key=>$row){
		if( $row =='on' )
			$_SESSION['filters'][__CLASS__]['viewstatus'][$key] = 'on';
		else
			unset($_SESSION['filters'][__CLASS__]['viewstatus'][$key]);
	}


	tep_redirect(tep_href_link(self::FILENAME));
break;

Section dans la function GetDBValue

Modifier la requêtes produisant le listing, en y portant la var des la liste des champs à extraire de la base.

$adjust=new objectInfo(self::$InitInfo['adjust']);


$query_raw = "select distinct ".$adjust->listfields." from " ....

mutli langue / langue active

23 avril 2012

Note !

 

Lors de l’ajout de donnée, la prise en charge de plusieurs langues ce fait naturellement, en ajoutant une langue dans la gestion de langue.

Il est toutefois important de savoir que cette langue ne sera considéré comme active, que dans la mesure ou les fichiers de langue correspondant seront présent. par defaut, seul les fichiers public sont recherchés.

 

Si le dossier de langue public n’est pas présent, alors la langue sera considéré comme inactive, et donc l’ajout de donnée ne ce fera que sur les langue active.

 

Dans ce contexte, aucun mécanisme de rattrapage des ligne manquante dans la base n’existe, il est donc important de mettre en place les fichier avant l’installation de la langue …….

Callback js dans les listing ajax

4 avril 2012

Les listing du backoffice sont chargé en ajax, aussi les fonction js non intrusive doivent être appliqué par l’intermédiaire de la fonction load_post_page(), qui est situé dans le fichier footer.php.

Dans ces page de listing, il peut être nécessaire d’intégrer des appels js (Toolip par ex) surle contenu de ce listing.  Il est donc nécessaire d’utiliser la fonction de callback contenu dans la classes oscss_cstr
Soit:

oscss_cstr::CallBack('Toolip();');

Note

  • la fonction Callback support un second argument, qui précise si le paramètre principal correspond à du code, ou un liens vers un fichier (code|file). Toutefois, à l’heure de ces lignes seul le mode par défaut est supporté.
  • la fonction Callback support un troisième argument, qui précise la pile dans laquelle la valeur sera stocké. Toutefois, à l’heure de ces lignes seul la pile par défaut est implémenté.

Les datatypes

2 avril 2012

mise à jour : 22/04/2012

La notion de datatype est apparu sur les versions 2.1.0 et ultérieure; Cette notion visent à rassembler au sein d’un fonctionnement normalisé l’ensemble des données publiés.

Les données publiées rassemblent les données de contenu , hors de donnée du fonctionnement propre du moteur.

Liste non exhaustive:

  • Les RootListing, transversales , elle permette de hiérarchiser les donné enfants: ( categorie, manufacturer )
  • Les donnée enfants, ordonnancé en listing , et contenant une page d’info unique : ( product, content, … )

Cette approche doit permettre de manipuler les données avec des outils synthétique, et dont la forme et les appels sont identiques.

D’autre part, ces données étant dynamique, elle peuvent dont ajouter/modifié le comportement des page public, quant à gestion et l’affichage.

 

dans les exemples et explications suivantes, nous partons sur la notion d’un datatype « xxx », couplé au categories

 

Lors de l’ajout d’un nouveau datatype, respecter les règles suivantes:

  • le nom du datatype doit être unique, et ne pas être déjà utilisé
  • le nom du datatype doit être au singulier
  • certain fichier sont optionnels, toutefois la

 

Les tables de données d’un datatype

Les tables doivent respecter la nomenclature de nommage courante :

  • osc_datatype
  • osc_datatype_description (gestion multi-langue)
  • osc_datatype_extra (optionnnel) peut être aussi remplacer par des extras complexe (cf extras des products)
  • osc_datatype_to_categorie (optionnel – liaison avec les categories)

 

La nomenclature des tables est importante, elle contient le nom des liaison entre datatype, et est utilisé dans la gestion avancé des tables et des backups. il est donc important de conserver une structure  de ce type.

Petit rappel :

  • séparateur  « _ » p
  • le non du datatype enfants en premier
  • le nom de la liaison en second, avec ‘to’ comme séparateur

 Les defines  de constantes associé à l’exploitation des tables dans le core sont assuré par le module Data_xxx. Tans dans le backoffice que le frontoffice. La désactivation d’un module rend donc les tables inaccessible via les constante !!

 

Les clef de tables, et définition de la clef primaire de chaque tables doit faire preuve d’une attention particulière. Ce sont ces éléments qui définissent la capacité du core a manipuler les tables dans différents contextes.  les clef primaires sont entre autre utilisé dans la manipulation du nombre de langue, et la duplication automatique des entrée nécessaire au bon fonctionnement du module.

Les fichiers et dossiers

Les define qui construise les constantes de nommage des fichier sont assuré par le modules Data_xxx.

Dossier /common/

Les modules sont nommé ‘Data_’.xxx ou xxx représente le nom du datatype.

Au sein de ce dossier centralisé, les drivers « datatype_drivers » assure la prise en charge des datatypes. Ce sont ces modules, qui détermine, en fonction des arguments GET et du nom de la page, si la page courante correspond a ce datatype, et le pré-chargement des classes spécifique au datatype courant.

D’autre part, ce module assure aussi la liaison avec la class seo, pour la construction des url spécifique à ce datatype, ainsi qu’au élément nécessaire à la construction du htaccess.

 

Dossier admin

le dossier admin peut quant à lui s’ordonner en fonction des besoins spécifique au datatype. Nous retrouverons toutefois les modules suivant

  • /modules/pages/datatypes.php  (gestion listing / affichage / édition des données)
  • /modules/datatype/ (Dossier  specifique au sous module du datatype courant)
  • /classes/drivers/sqldatatype.php la class sql de manipulation des données de manière structuré

Dossier public

La structure du dossier public peut être plus ou moins ajusté, nous respecterons néanmoins la nomenclature suivante:

  • /classes/drivers/data/datatype.php (la class public principale de manipulation des données de ce datatype)
  • /content/ (le fichier nécessaire à la visualisation d’une datatype unique – défini dans le module Data_datatype de  common)

 

Transversalité de certain module entre eux

Certain module de datatype sont un peu spécifique, compte tenu qu’il inter-agissent avec d’autre module de datatype (categorie / fabricant).

Il est à la charge du module transversale de prendre en charge le couplage (listing requête sql) des autres datatypes;

Une variable de configuration est définit pour chaque RootListing nommé « DATATYPES_ROOTLISTING__xxx » du nom du datatype, elle contient la liste (séparé par une virgule) des datatype auquelles elle est couplé.

 

Dev/GenerCode Modele : datatype

Un modèle de datatype existe dans la section dev/GenerCode; il s’agit d’un générateur de code succinct qui ce contente de construite l’ensemble de la structure de base d’un datatype de type contenu enfant ( idem product/content).

L’intérêt de cette méthode, et que l’extension de votre datatype construit, il vous suffit de l’ajuster à vos besoin.  les fichiers existe dans une extension destiné à l’installateur d’oscss, que ce soit en backoffice ou frontoffice. De même que l’ensemble des tables, liaison, define , entrée dans les menu, etc.. sont mise en œuvre entre les fichier et l’install.xml

Les tables créer ne contiennent que les champs minimaux structurel. Charge a vous d’ajuster les colonnes ainsi que les gabarit html et gestion des enregistrement.

 

Gestion / Intégration dans le front office, exploitation et usage

 

l’usage des datatypes, dans l’environnement public, et l’intégration de vos template reste assez transparent. Les listing sont gérer sans

 

Les Listing

le listing ce construit automatiquement sur la base des catégories. La liaison du datatype aux catégorie, vous à donné accès à la création de catégorie typée sur ce datatype, soit xxx. La Classes listing de la section core_page du dossier classes, assurera donc la recherche ordonnée des entrées de ce datatype dans cette/ces categories.

note: le calcul effectué ne rassemble que les id du datatype, et non les données de chaque ligne.

Aussi , le listing se construira automatiquement , et son détail (le détail des données de chaque ligne ) sera assuré par le module standard ‘listing.php’ des modules non-typés (il vous est bien sûr possible de personnaliser ces appels et de construire un module spécifique destiné au listing).

 

La page xxx_info.php | info_xxx.php

Cette page est la section destinée à l’affichage unique de cette ressource. Elle sera donc très dépendantes des colonnes des tables principales , et des données associées.

Il est donc nécessaire de construire cette page sur mesure.

Rappel :

le détail de la ressource

$object_data = xxx::get_item($id);

 

sur la page info, l’appel est déjà calculé, aussi un simple appel à la pile suffit:

$object_data =$page->GetVar('xxx');

alias – rétro-compatibilité

$object_data =$page->the_var('xxx');

L’appel à vos sous module aca:

$module=$page->_call('xxx','ret_modules');

 

 

Liens et SEO

La gestion de la ré-écriture d’url , accompagné de l’ajustement du htaccess reste absolument transparente. Noter que vous devez avoir mise en place un module aca header_tag dans ce datatype coté admin.

L’ensemble de la ré-ecriture sera assuré par le Data_xx.  Quelque soit le module de ré-ecriture choisi.

htaccess

Le contenu du fichier est produit dans le back-office, celui-ci prendra en charge tous les datatype présent lors de son exécution. Si vous activez un nouveau datatype, pensez a mettre a jour votre htaccess public

 

La recherche avancé

La encore, c’est le Data_xxs qui va prendre en charge la gestion de la construction des requêtes sql, couplé avec les catégories. Noté que si vous souhaitez couplé la recherche à un formulaire plus complet et éventuellement avec d’autre Rootlisting (categorie en est un , manufacturer un autre); vous devrez ajuster le Data_xxx

Seuls les critères de base sont configurés.

Un gabarit html (fichier .gab)  peut être définis dans le tableau retourné par le datatype, dans ce contexte, le sous gabarit utile apporte les champs de formulaire complémentaire

gestion de l’encryptage des mot de passe

31 mars 2012

La version 2.1.1 apporte la possibilité de prendre en charge différente forme encryptage des mots de passe.
Cette option , permet donc plus de souplesse, et dans le cas d’un import d’un d’une version précédente, ou d’une base externe, il est ainsi possible d’ajuster le type de mot de passe, sans avoir a régénérer l’ensemble des accès client.

Le mode d’encryptage est déterminé par le fichier configure, et peut être différente entre le back-office et le front office.

Trois modules sont fournis

  • Classic qui correspond à l’encryptage original des version précédente d’oscss, et d’oscommerce. Il couple un cryptage md5 à une clef interne unique
  • Md5, une classique empreinte
  • Sha1, le cryptage utilisé par défaut lors d’une nouvelle installation

Voir les fichiers configure

exemple

    /**
    @var Define class use for encrypt password
    Value possible:
    - Classic normal in oscommerce mode
    - Md5 special for acces by other mode
    - Sha1 new mode
    */
    $conf['ModPassword'] = 'Classic';

Images , watermark et format

27 mars 2012

il est possible de preciser quel format sera utilisé dans les redimensionnement (par default, l’image respectera la propotion sur la largeur et la hauteur)

Pour forcer le redimensionement en carré, en utilisant le module present, il faut placer dans le fichier du template :

image_ratio::SetModele('Carre');

Pour utiliser un watermark

Ajouter dans la configuration, le texte souhaité, puis activer l’utilisation du watermark avec:

image_ratio::SetModeleSetWatermark(true);

modification des modules non type a partir de la version 2.1.1

31 décembre 2011

Vous migrez votre template d’un osCSS 2.1.0 à la nouvelle version en cours de dev. Dans l’affichage de vos page, les modules non typé n’affiche plus rien ?

Il s’agit d’un petite evolution de ces modules. Le module DOIT renvoyer le type de donnée qu’il traitent. C’est cette indication qui est utilisé dans les boucles associées au modules.

Pour corriger ce probleme, ajouter dans les function  » in_obj_xxx », dans la boucle de traitement des donnée , l’informations comme suit:
Avant

 while ($listing_version_products = $res->fetchAssoc()){
 $pd=product::get_item($listing_version_products['products_id']);
 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);
 $p[]=$pd;
 }
 return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p));

Apres

while ($listing_version_products = $res->fetchAssoc()){
 $pd=product::get_item($listing_version_products['products_id']);
 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);
 $pd->type='product';
 $p[]=$pd;
 }
return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p ,'type'=>'product'));