fdisk -l
permet de lister les disques présents
dans mon cas je vois un /dev/sdb
j'ai suivi ça : http://doc.ubuntu-fr.org/tutoriel/comment_ajouter_un_disque_dur
cfdisk /dev/sdb
new
ext3
...
J'ai maintenant une partition /dev/sdb1
formatage :
mkfs.ext3 /dev/sdb1
Montage :
Création du répertoire /mnt/data
puis
Dans /etc/fstab, ajout de la ligne :
/dev/sdb1 /mnt/data ext3 defaults 0 0
Et voilà !
Rechercher dans ce blog
lundi 6 février 2012
mercredi 7 septembre 2011
Alfresco 3.4d : authentification par le contrôleur de domaine
Voici comment donner l'accès au CIFS et à l'interface WEB avec le login Windows et sans avoir besoin de le saisir !
Tout d'abord l'arborescence à créer :
Ensuite on va créer les fichiers nécessaires.
Tout d'abord, il faut modifier le fichier de configuration alfresco-global.properties sous tomcat\shared :
on le complète avec ces lignes (mon serveur Alfresco se nomme SERVER-ALF, mon domaine est TOTO) :
Remarque : ce fichier contient aussi la configuration pour CIFS
Puis, sous alfrescoNtlm1 on copie depuis webapps\..\subsystems\Authentication\alfrescoNtlm les 2 fichiers alfresco-authentication-context.xml et ntlm-filter-context.xml.
Ensuite on créé le fichier alfresco-authentication.properties :
Ensuite on créé le fichier ntlm-filter.properties
Sous ldap1 on créé le fichier ldap-ad-authentication-context.xml
Pour le fichier de configuration suivant, il faut s'adapter à l'AD. Dans mon AD (le serveur contrôleur de domaine a l'IP 192.168.0.1) j'ai un domaine toto.adds puis sous ce domaine, j'ai une UO TOTO puis sous cette UO j'ai une UO ALFRESCO dans laquelle se trouve un groupe group_alfresco dans lequel (ouf !) se trouvent mes utilisateurs d'Alfresco.
Voici donc le fichier ldap-ad-authentication.properties (je suis parti de la base du même fichier sous webapps\..\subsystems\Authentication\ldap-ad)
Enfin, sous passthru1 on copie depuis webapps\..\subsystems\Authentication\passthru les 2 fichiers passthru-authentication-context.xml et ntlm-filter-context.xml.
Puis on créé le fichier passthru-authentication-context.properties (le serveur controleur de domaine se nomme SERVER)
Et le dernier, on créé le fichier ntlm-filter.properties
Voilà !
Je ne suis pas sûr de la nécessité des mutliples fichiers ntml-filter.properties, mais bon ça marche comme ça, j'ai pas testé en n'en laissant qu'un.
Le problème que j'ai rencontré ensuite, c'est que la machine qui se connecte su Alfresco doit le faire depuis une session ouverte sur le domaine (TOTO\utilisateur ou utilisateur@toto.adds) sinon la connexion ne se fait pas (demande du loggin mais erreur et ne se logge pas).
Mon serveur Alfresco se nomme SERVER-ALF, le nom pour le CIFS apparait normalement sous SERVER-ALFA (ça peut se changer mais ça me va)
Tout d'abord l'arborescence à créer :
Ensuite on va créer les fichiers nécessaires.
Tout d'abord, il faut modifier le fichier de configuration alfresco-global.properties sous tomcat\shared :
on le complète avec ces lignes (mon serveur Alfresco se nomme SERVER-ALF, mon domaine est TOTO) :
Remarque : ce fichier contient aussi la configuration pour CIFS
Puis, sous alfrescoNtlm1 on copie depuis webapps\..\subsystems\Authentication\alfrescoNtlm les 2 fichiers alfresco-authentication-context.xml et ntlm-filter-context.xml.
Ensuite on créé le fichier alfresco-authentication.properties :
Ensuite on créé le fichier ntlm-filter.properties
Sous ldap1 on créé le fichier ldap-ad-authentication-context.xml
Pour le fichier de configuration suivant, il faut s'adapter à l'AD. Dans mon AD (le serveur contrôleur de domaine a l'IP 192.168.0.1) j'ai un domaine toto.adds puis sous ce domaine, j'ai une UO TOTO puis sous cette UO j'ai une UO ALFRESCO dans laquelle se trouve un groupe group_alfresco dans lequel (ouf !) se trouvent mes utilisateurs d'Alfresco.
Voici donc le fichier ldap-ad-authentication.properties (je suis parti de la base du même fichier sous webapps\..\subsystems\Authentication\ldap-ad)
Enfin, sous passthru1 on copie depuis webapps\..\subsystems\Authentication\passthru les 2 fichiers passthru-authentication-context.xml et ntlm-filter-context.xml.
Puis on créé le fichier passthru-authentication-context.properties (le serveur controleur de domaine se nomme SERVER)
Et le dernier, on créé le fichier ntlm-filter.properties
Voilà !
Je ne suis pas sûr de la nécessité des mutliples fichiers ntml-filter.properties, mais bon ça marche comme ça, j'ai pas testé en n'en laissant qu'un.
Le problème que j'ai rencontré ensuite, c'est que la machine qui se connecte su Alfresco doit le faire depuis une session ouverte sur le domaine (TOTO\utilisateur ou utilisateur@toto.adds) sinon la connexion ne se fait pas (demande du loggin mais erreur et ne se logge pas).
Mon serveur Alfresco se nomme SERVER-ALF, le nom pour le CIFS apparait normalement sous SERVER-ALFA (ça peut se changer mais ça me va)
Alfresco 3.4d - scripts manquants ou ne fonctionnant pas
De base le script apply_amps.bat ne fonctionne pas.
Voici le fichier modifié pour que ça marche.
Mon installation d'Alfresco est sous C:\Alfresco
apply_amps.bat :
Voici maintenant le fichier clean_tomcat.bat modifié :
clean_tomcat.bat :
J'ai supprimé tous les amp présents de base dans le répertoire C:\Alfresco\amps
Maintenant on peut mettre son amp dans le répertoire C:\Alfresco\amps et dans une fenêtre de commande aller dans C\Alfresco\bin et lancer apply_amps.bat
J'ai aussi rencontré un léger soucis dû à mon amp qui apparemment n'avait pas les bons droits d'accès pour l'utilisateur en cours (il n'apparassait pas dans la liste des amps installés alors qu'il était bien présent dans le répertoire "amps"). Un passage par le bureau pour lui attribuer les bons droits et hop.
Edit : en fait c'était plus lié à la présence des autres amps, car par la suite j'ai rencontré à nouveau ce problème et la simple suppression des amps déjà présents a suffit.
J'ai aussi besoin de réinitialiser la base de données, voici les scripts :
Pour la réinitialisation :
db_remove.sql :
db_setup.sql :
db_remove_and_setup.bat :
J'ai rencontré un problème de mot de passe, car il était différent dans mon alf.sql que celui d'origine de l'installation. Il a donc fallu le mettre à jour dans le fichier de config d'Alfresco (C:\Alfresco\tomcat\shared\classes\alfresco-global.properties lignes :
Voici le fichier modifié pour que ça marche.
Mon installation d'Alfresco est sous C:\Alfresco
apply_amps.bat :
Voici maintenant le fichier clean_tomcat.bat modifié :
clean_tomcat.bat :
J'ai supprimé tous les amp présents de base dans le répertoire C:\Alfresco\amps
Maintenant on peut mettre son amp dans le répertoire C:\Alfresco\amps et dans une fenêtre de commande aller dans C\Alfresco\bin et lancer apply_amps.bat
J'ai aussi rencontré un léger soucis dû à mon amp qui apparemment n'avait pas les bons droits d'accès pour l'utilisateur en cours (il n'apparassait pas dans la liste des amps installés alors qu'il était bien présent dans le répertoire "amps"). Un passage par le bureau pour lui attribuer les bons droits et hop.
Edit : en fait c'était plus lié à la présence des autres amps, car par la suite j'ai rencontré à nouveau ce problème et la simple suppression des amps déjà présents a suffit.
J'ai aussi besoin de réinitialiser la base de données, voici les scripts :
Pour la réinitialisation :
db_remove.sql :
db_setup.sql :
db_remove_and_setup.bat :
Pour l'injection des données existantes (après un dump de la base)
set_alfsql.bat :
J'ai rencontré un problème de mot de passe, car il était différent dans mon alf.sql que celui d'origine de l'installation. Il a donc fallu le mettre à jour dans le fichier de config d'Alfresco (C:\Alfresco\tomcat\shared\classes\alfresco-global.properties lignes :
db.username=alfresco
db.password=*****
)
mercredi 31 août 2011
CIFS Alfresco sous Windows Server 2008R2
Ce Windows server 2008R2 est dans une machine virtuelle (SERVER-ALF) sous Hyper-V.
Installation d'Alfresco community 3.4d 64 bits de base.
Lorsque j'ai eu mon premier fonctionnement en local, c'est le firewall de SERVER-ALF qui me bloquait l'accès distant.
Installation d'Alfresco community 3.4d 64 bits de base.
- Désactivation de "Partage de fichiers et imprimantes Réseaux Microsoft" dans la carte réseau.
- Arrêt du service "Serveur"
- Ajout de la clé Smb2 de type REG_DWORD et de value =0 sous [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters]
- Ajout des lignes suivantes dans c:\windows\system32\drivers\etc\hosts
127.0.0.1 localhost
::1 localhost
pour pouvoir tester en local - dans share\alfresco-global.properties
filesystem.name=Alfresco
cifs.enabled=true
cifs.servername=SERVER-ALF
cifs.domain=jr
cifs.hostanounce=true
cifs.ipv6.enabled=false - firewall éteint. A modifier pour ouvrir les bons ports(445...)
Test en local :
nbtstat -n doit afficher SERVER-ALFA
netstat -an ne doit pas afficher le port 445
en double-cliquant sur SERVER-ALFA, la boite de login apparait, on entre juste le nom et le mot de passe (pas toucher au domaine...) et ça doit passer et afficher Alfresco et avm comme dossiers partagés
Test distant :
SERVER-ALFA\Alfresco doit afficher la boite de login, faire comme au-dessus.
SERVER-ALFA doit afficher les deux dossiers de partage
Lorsque j'ai eu mon premier fonctionnement en local, c'est le firewall de SERVER-ALF qui me bloquait l'accès distant.
mercredi 29 juin 2011
MadExcept
Encore un bug Delphi...
Pour que madExcept puisse patcher l'exe produit après compilation par delphi il ne faut pas utiliser la compilation par le gestionnaire de projet sur la config de construction voulue (par clic-droit, compiler ou construire) mais toujours utiliser par le menu Projet/Compiler ou Construire.vendredi 15 avril 2011
Alfresco : rediriger alf_data sur un dossier réseau
Il faut bien sûr éditer le fichier /tomcat/shared/classes/alfresco-global.properties :
Puis il faut changer cette ligne : dir.root=c:/alfresco/alf_data
Le problème est que si on monte un lecteur réseau sur ce dossier réseau, par exemple :
si on a S: qui pointe sur //serveur/partage/alf_data
et que l'on change dir.root en :
dir.root=S:/alf_data
Ca ne marche pas ! Même avec tous les droits sur le dossier.
Par contre si on le change en :
dir.root=//serveur/partage/alf_data
(attention aux / et pas \)
Et bien là ça marche !
Et voilà !
Puis il faut changer cette ligne : dir.root=c:/alfresco/alf_data
Le problème est que si on monte un lecteur réseau sur ce dossier réseau, par exemple :
si on a S: qui pointe sur //serveur/partage/alf_data
et que l'on change dir.root en :
dir.root=S:/alf_data
Ca ne marche pas ! Même avec tous les droits sur le dossier.
Par contre si on le change en :
dir.root=//serveur/partage/alf_data
(attention aux / et pas \)
Et bien là ça marche !
Et voilà !
lundi 11 avril 2011
Tortoise SVN : merger une branche sur le trunk
Avec la méthode normale impossible pour moi de merger une branche sur le trunk (Error: Cannot reintegrate into mixed-revision working copy; try updating first), pourquoi ???
J'ai trouvé cette méthode (d'après http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2425683) qui fonctionne mieux.
Avant tout, faire un commit de la branche (ex : \branches\dev.9.1.8) et le trunk (ex : \trunk).
Ensuite :
Clic-droit sur le répertoire de la branche voulue (ex : \branches\dev.9.1.8) puis TortoiseSVN\ShowLog
Clic-droit sur la dernière révision puis Merge Revision to...
Là choisir le répertoire \trunk et valider.
Le merge se produit sans erreur et semble être correct dans mon essai.
On verra bien par la suite si ça fonctionne toujours correctement...
Edit du 18/10/2011
Après avoir fait évoluer le canal trunk sans le merger à chaque commit sur le canal dev.9.1.8, j'ai dû faire le merge de ce trunk très différent sur la version dev.9.1.8.
La méthode ci-dessus n'a pas fonctionné : le merge était incomplet, certaines sources partiellement à jour, très dangereux car compilable mais avec omission de lignes de codes !!
Pour y arriver j'ai dû changer de méthode.
J'ai fait un clic-droit sur la branche dev.9.1.8 puis merge..., Merge a range of revisions, merge from : .../trunk
Et là après vérification par comparaison des poids en octets des fichiers, j'ai pu valider le merge des sources.
Ouf !
J'ai trouvé cette méthode (d'après http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2425683) qui fonctionne mieux.
Avant tout, faire un commit de la branche (ex : \branches\dev.9.1.8) et le trunk (ex : \trunk).
Ensuite :
Clic-droit sur le répertoire de la branche voulue (ex : \branches\dev.9.1.8) puis TortoiseSVN\ShowLog
Clic-droit sur la dernière révision puis Merge Revision to...
Là choisir le répertoire \trunk et valider.
Le merge se produit sans erreur et semble être correct dans mon essai.
On verra bien par la suite si ça fonctionne toujours correctement...
Edit du 18/10/2011
Après avoir fait évoluer le canal trunk sans le merger à chaque commit sur le canal dev.9.1.8, j'ai dû faire le merge de ce trunk très différent sur la version dev.9.1.8.
La méthode ci-dessus n'a pas fonctionné : le merge était incomplet, certaines sources partiellement à jour, très dangereux car compilable mais avec omission de lignes de codes !!
Pour y arriver j'ai dû changer de méthode.
J'ai fait un clic-droit sur la branche dev.9.1.8 puis merge..., Merge a range of revisions, merge from : .../trunk
Et là après vérification par comparaison des poids en octets des fichiers, j'ai pu valider le merge des sources.
Ouf !
Inscription à :
Articles (Atom)