Installer un serveur SFTP

Pour échanger des fichiers en toute sécurité…
Le cahier des charges était simple : Echanger avec l’extérieur des fichiers de manière sécurisée.
Après quelques recherches, je suis tombé sur ce logiciel : MySecureShell.
Fonctionnant sous tout système UNIX, il s’agit d’un shell qui utilise OpenSSH (pré-requis d’installation).
Cependant, une installation sous Solaris est plus complexe que prévue (des scripts livrés contiennent des incompatibilités par exemple).
Plus de détails ici : Site MySecureShell.
L’installation complète se fait en 5 étapes :

  • Vérification des pré-requis, voire leur installation
  • Compilation (configure, puis make)
  • Installation (placer les binaires au bon endroit)
  • Configuration (éditer un simple fichier)
  • Créer des comptes utilisateur associés au shell MySecureShell : adduser -s /usr/bin/MySecureShell user1

Un seul port est nécessaire pour les communications (port 22), et WinSCP s’avère être un très bon client SFTP (alors que Filezilla n’est pas conseillé).

Tâches difficiles ? Utilisez le Windows Install CleanUp

Comment rattraper une désinstallation hasardeuse…
Un jour j’ai eu la bonne idée de désinstaller « à la main » un JDK… (c’est à dire supprimer tout le contenu du répertoire où le JDK était installé).
Ce n’est pas bien me direz-vous… Soit ! Mais ma mauvaise conduite fut punie : impossible de réinstaller un nouveau JDK. Le programme d’installation pense qu’il y en a toujours un d’installé. Il essaie de le désinstaller, mais il n’y arrive pas ! (rien en base de registre et même à coup de CCleaner!)
Heureusement, il existe le produit miracle : le Windows Install CleanUp
Cette petite chose de 40 kilo permet d’effacer les traces de programmes à « Ajouter/Supprimer » (Windows Installer).
Techniquement, je ne sais pas comment ça fonctionne, mais ça m’a sorti de cette galère…
Lien : Windows Install CleanUp

MOSS : Un bon outil de stats

Voici un outil très simple à déployer et qui permet d’avoir des stats bien plus sympa que l’outil natif de MOSS :
http://www.mapilab.com/download/
(c’est un freeware, il suffit de s’inscrire)
Entre autres :

  • Exports PDF
  • Stats sur les recherches les plus fréquentes
  • Temps de consultations
  • Présentations sous forme de courbes, tableaux (avec tris et groupement…)
  • etc……..

Petit détour vers Linux

Installation d’un serveur web JAHIA sur une distribution Fedora pour un newbie en la matière.
A part quelques commandes du bash, et des TP durant ma vie étudiante, je n’ai pas beaucoup mis les pieds dans le fussoir Linux.
Là, ça y est, je dois installer une appli web (Jahia) sur un serveur Fedora 9.
C’est parti, je « tweet » en live :

  • Installation de fedora sous WMWare : super simple.
  • Tiens, au lancement, Fedora me lance un « Kernel Failure »… Je dois répondre « toujours », « oui », « non », « jamais ». Bon ben « jamais » alors 🙂
  • Déjà, Fedora, c’est quoi ? On s’en fout, c’est un bastringue dont le noyau est Linux.
  • Le terminal : aussi planqué que la console sous windows.
  • Connaitre son adresse IP sous bash : ifconfig.
  • J’essaie de partager des fichiers entre mon hôte windows et fedora… Galère.
  • Samba (j’avais déjà entendu ce nom là qq-part !) refuse de monter quoique ce soit.
  • Je comprends rien, je ne ping rien… Même pas mon hôte.
  • CA Y EST ! J’ai réussi à copier un fichier de mon hôte windows à fedora :
    – J’ai mis mon VMWare en network « host-only »
    – J’ai créé un dossier partagé sous windows, avec comme permission « Tout le monde »
    – J’ai ouvert un « Poste de travail » sous fedora, puis fait « Fichier > Ouvrir un emplacement »
    – J’ai taper : "smb://xxx.xxx.xxx.xxx/nom_du_dossier_partage_sous_windows" (avec « smb » comme Samba)
    – On me demande un login, mot de passe : je remplis avec mon compte de connexion windows
    – Et voilà, j’accède au contenu du dossier !
  • NB : xxx.xxx.xxx.xxx = l’adresse IP du network adapter créé par VMWare (faire ipconfig sous windows).
  • – Déclarer une variable d’environnement : export MA_VAR=ma_valeur
  • – Faire set pour avoir la liste des variables.
  • – Installation de JDK : Impecc’ ! Ce sont des fichiers .rpm.bin, qui se lance avec un simple sh.
  • – Installation de Jahia : tout aussi simple.
  • – Lancement de Jahia : il faut se mettre dans le bon dossier, sinon le .sh se perd dans les tréfonds de l’arborescence lol
  • – Et bam, catalina.sh = accès refusé. Je ressors mes cours de chmod 🙂 (chmod +x catalina.sh et c’est réglé.)
  • Mon site existe bien sur http://localhost:8080.

Mission accomplie 🙂

MOSS 2007 : Activer les statistiques d’un site

Comment accéder à de magnifiques rapports d’utilisation du site ? (camemberts, diagrammes…)
Voici les 3 manipulations à effectuer pour activer les statistiques sur un site MOSS :

  • Activer le journal de traitement de l’analyse
  •  » Admin centrale Sharepoint > Opération > Traitement de l’analyse de l’utilisation « 
  • Cocher  » Activer le journal « 
  • Emplacement : Donner (pourquoi pas) le même répertoire que les logs wss.
  • Nombre de fichiers : Nb de serveurs de BDD * 3 (préconisation MS).
  • Cocher  » Activer le traitement « .
  • Donner un intervalle de temps d’au moins 1/2 heure, le midi ou le soir.
  •  » OK « 

Dans les services partagés du site :

  • Cliquer sur « Rapports d’utilisation » dans la section « Rapports d’utilisation d’Office SharePoint ».
  • Cocher les deux cases, et faire « OK »

L’URL de la page qui va contenir les stats du site est :
http://mon_site/_layouts/SPUsageWeb.aspx

MOSS 2007 : Error logs 6482 7076 et 6398 toutes les minutes.

Solution naturelle à un bug surnaturel.
Comment réussir à stopper net ces trois erreurs récurrentes du minuteur : 6482, 7076 et 6398 ?
Pour ma part, j’avais toute les minutes ces erreurs de générées dans le journal des événements.
Les messages ressemblaient à ça : “ Old format or invalid type library ” ("Ancien format ou bibliothèque de types non valide") ou “ Not enough storage ” ("Espace insuffisant pour traiter cette commande").
Pour autant, ma ferme SharePoint fonctionnait normalement.
Solution :Installer les deux KB suivants disponibles via ce lien :

  • KB923028
  • KB918642

Ces vilaines traces devraient disparaitre… MSDN ? Lave plus blanc que blanc.

SQL Server : Fichier de Log (.LDF) qui devient énorme.

Comment diminuer de taille le fichier de transactions en un seul script SQL ?
Lorsqu’une base de données est en mode de récupération « Full » (Complète), les fichiers journaux .LDF peuvent devenir énormes (toutes les transactions sont enregistrées).
En lancant le script SQL ci-dessous, vous allez sauvegarder vos bases et fichiers de transaction, et diminuer la taille du fichier LDF :

-- Sauvegarde complète
BACKUP DATABASE MaBase TO DISK = ’S:mssqlMaBase.bak’
GO
BACKUP LOG MaBase TO DISK = ’S:mssqlMaBase_log.bak’
GO
USE MaBase
GO
-- (MaBase_log est le nom LOGIQUE du fichier LDF physique... A vérifier donc !)
DBCC SHRINKFILE(MaBase_log)
GO

NB : le fait de faire une sauvegarde complète d’une BDD vide le fichier de log « LDF »… mais ne diminue pas sa taille ! C’est pourquoi il faut faire un SHRINKFILE.
NB2 : C’est pourquoi il est important de faire une sauvegarde complète une fois par jour, afin d’empêcher le fichier LDF de grossir démesurément (le fichier se « videra » puis l’espace sera réutilisé…)
NB3 : Il faut également réfléchir à passer en mode de récupération SIMPLE. Le fichier LDF ne grossira pas autant, mais la perte de données admissible en cas de crash sera plus grande.
 

MOSS 2007 : Problème de backup dans une topologie 3-tiers

Dans une topologie 3-tiers (1 serveur de BDD, 1 serveur d’admin WSS, 1 serveur web frontal), il est important de respecter certaines proconisations pour lancer un stsadm -o backup :

  • Utiliser un chemin UNC (\SERVERNAMEetc.) pour décrire le chemin physique de stockage du fichier de backup. En effet, le serveur de BDD va écrire dans ce répertoire. Etant donné qu’il est « distant », il faut lui donner un chemin d’accès adéquat.
  • Donner les droits d’écriture pour ce répertoire au compte de service de SQL Server.

MOSS 2007 : Les liens relatifs vers les bibliothèques de connexions de données situées sur des collections de sites SharePoint différentes ne sont pas pris en charge.

Cette erreur peut arriver lorsque vous publiez un formulaire Infopath même si vos connexions de données viennent de la même bibliothèque !
Cette erreur n’a alors aucune raison d’être, vu que toutes vos connexions font bien partie de la même collection de site.
Que se passe-t-il ? Voici le problème que j’ai rencontré, et qui arrive assez fréquemment :
Editez le fichier manifest.xsf avec le bloc note.
Allez sur les lignes où sont déclarées toutes les connexions (xsf2:adoAdapterExtension ou xsf2:webServiceAdapterExtension).
Maintenant comparez bien les attributs siteCollection… la moindre majuscule de différence, et l’erreur surgira !
Il faut bien que toutes les attributs siteCollection des balises xsf2:connectoid soient parfaitement identiques, à la majuscule près !