Discussion :

[delta07]

Bonjour à tous

Je viens dans les méandres d'un coin les plus barbus de ce forum (enfin je suppose), car je me retrouve bloqué .
Je suis évidemment un débutant total en Solaris.

J'ai deux zones Solaris distinct. dv2 et dv3 (considérées comme deux machines bien différentes).

Je fais des packages sous dv2 que je dois déployer sous dv3.
Je dois cependant à la fin de l'installation de ce package changer les nom de machine, sur lequel j'ai fait le package, en dur dans certain fichier par le nom de machine sur lequel j’installe ce package. En gros je dois remplacer "dv2" par "dv3" dans certain fichier. Ces fichiers que je dois modifier sont en fait tous les fichiers non-binaire listés dans le prototype de mon package.
Mais je dois faire ce traitement en fin d’installation, c'est donc naturellement que j'ai voulu le faire a la fin de mon fichier postinstall.

Problème, le fichier "prototype" n’existe apparemment plus a la fin de l’installe sur dv3 puisqu'il ne liste que les fichiers a exporter lors de la création du package.
Ou puis-je alors retrouver ma liste de fichier contenu dans mon prototype lors de la création du package alors que je suis sur la machine d'installation ?

Surtout que lors de l'installation je suis dans certain dossier dans lesquels je n'ai apparemment pas les droits, je ne comprend pas l'arborescence qu'il utilise pour l’installe. Bref le problème est certainement très simple, je voudrais juste récupérer le contenu de mon fichiers "Prototype" a la fin de mon "postinstall".

J'ai bien penser a inclue le fichier prototype dans le prototype lui même, mais je sens que ça va être la catastrophe...

Je suis preneur de tous conseils.

Merci de votre aide.

[jlliagre]

Avoir un nom de machine en dur dans les fichiers d'un package n'est pas une bonne pratique (pour rester poli )

L'ideal serait que ces fichiers utilisent une variable qu'il suffirait d'affecter une seule fois, et qui pourrait même être affectée automatiquement.

Si tu souhaites quand même un post-traitement, tu peux récupérer la liste de tous les fichiers faisant partie d'un package donné avec la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pkgchk -v MONpackage

[delta07]

Hello, je répond un peu tard, ponts de mai obligent

Merci en tous cas de la réponse.

Pour ce qui est des noms en dur, je suis complétement d'accord, mais je n'ai pas le choix. Historique et contraintes clients font que pour l'instant on n'a pas d'autre solution.

Pour la commande, je suis désolé mais je me suis mal exprimé. Je créé des PATCH et non des package. MéaCulpa. Cela prouve bien mon incompétence solarisienne :/
Du coup la liste des fichiers du package ne me sert a rien. Je tente toujours de trouver une solution pour avoir la liste des fichier modifiée par un PATCH.

Merci et désolé de l'erreur de débutant.

[jlliagre]

Comment as tu généré tes patchs, vu que la procédure n'est pas documentée ?

[delta07]

j'exécute ça dans le dossier de mon patch

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pkgmk -o -d /le/chemin/ou/je/met/mon/patch -b/ -r/

et ça me créer mon patch a l'endroit indiqué

[jlliagre]

pkgmk crée un package, pas un patch :

http://docs.oracle.com/cd/E26505_01/...pkg-17051.html

[delta07]

Pourtant, lorsque je transfère ces "patchs" sur mon autre machine, je les installe bien par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo patchadd xxx

Et lorsque c'est un "package" que j'installe c'est un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo pkgadd xxx.pkg

donc, je ne comprend pas bien les nuances, et je vois de moins en moins de solution a mon problème du coup

[jlliagre]

Un package contient essentiellement un ensemble de répertoires et fichiers à installer + des scripts de pré/post installation. Un même fichier ne peut pas être fourni par deux packages différents (installés).

Un patch contient un ensemble de fichiers destinés à remplacer des fichiers précédemment fournis pas un ou plusieurs packages.

Il y a quoi dans xxx ?

[delta07]

Avant le pkgmk j'ai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/users/xxxxxx/xxxxxxx_ToTest > ls -al
total 87
drwxrwxr-x   2 srmadmin exploit       14 May 12 11:34 .
drwxr-xr-x  31 srmadmin exploit       49 May 15 16:33 ..
-rw-rw-r--   1 srmadmin exploit     5143 Apr 17 15:33 checkinstall
-rw-rw-r--   1 srmadmin exploit     5335 Apr 17 15:33 i.none
-rw-rw-r--   1 srmadmin exploit     2383 Apr 17 15:33 patch_checkinstall
-rw-rw-r--   1 srmadmin exploit      824 Apr 17 15:33 patch_postinstall
-rw-rw-r--   1 srmadmin exploit      231 Apr 17 15:35 pkginfo
-rw-rw-r--   1 srmadmin exploit     7417 Apr 29 15:49 postinstall
-rw-rw-r--   1 srmadmin exploit     6559 Apr 30 14:45 preinstall
-rw-rw-r--   1 srmadmin exploit      158 Apr 28 09:24 prototype
-rwxrwxr-x   1 srmadmin exploit     1091 Apr 24 14:55 script

et après

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
/users/xxxx> ls -al /xxx/xxxx/xxxxx/xxxxx_ToTest/xxxxxx/
total 8
drwxr-xr-x   4 srmadmin exploit        6 May 15 16:35 .
drwxrwxr-x   3 srmadmin exploit        4 May 15 16:35 ..
drwxr-xr-x   2 srmadmin exploit        8 May 15 16:35 install
-rw-rw-r--   1 srmadmin exploit      262 May 15 16:35 pkginfo
-rw-rw-r--   1 srmadmin exploit      353 May 15 16:35 pkgmap
drwxr-xr-x   3 srmadmin exploit        3 May 15 16:35 root

[jlliagre]

Hmm, c'est bien d'un patch qu'il s'agit. Tu m'auras appris quelque chose, merci ! Des patchs créés hors engineering Solaris, il ne doit pas en avoir beaucoup dans la nature ...

Contrairement à ce que je croyais, la procédure de création de patch est donc documentée depuis quelque années, j'avais loupé cette info: http://docs.oracle.com/cd/E19683-01/...c4t/index.html

Tu devrais pouvoir trouver la liste des fichiers modifiés en explorant le répertoire "root".

[delta07]

De rien, ce n'était pas volontaire ^^ Je me retrouve à devoir faire avec ce qu'on me donne et l'historique de l'appli :/ Juste par curiosité, qu'appel tu "Solaris engineering" ?

Sinon, oui j'avais vu que dans root/ il y avait la liste, et même l'arborescence des fichiers. Cependant, lorsque le patch st installé, j'ai l’impression que Solaris dépaquetage tout dans /var/quelque chose avant de tout installer, et dans ce dépaquetage, impossible de retrouver le root/ du patch.

Si je veux que cela soit générique je ne peux pas me fier non plus à l’endroit ou on dépose le patch avant l'install.

Je m'attendais a une commande ou a un fichier temps, accessible avant la fin total de l'install du patch, mais ça semble bien plus compliqué...

[jlliagre]

De rien, ce n'était pas volontaire ^^ Je me retrouve à devoir faire avec ce qu'on me donne et l'historique de l'appli :/ Juste par curiosité, qu'appel tu "Solaris engineering" ?

Les développeurs qui travaillent chez Oracle et développent Solaris et les autres logiciels packagés par Oracle (et Sun auparavant), par opposition aux développeurs d'autres éditeurs et de la communauté open source qui peuvent aussi créer des packages Solaris.

Sinon, oui j'avais vu que dans root/ il y avait la liste, et même l'arborescence des fichiers. Cependant, lorsque le patch st installé, j'ai l’impression que Solaris dépaquetage tout dans /var/quelque chose avant de tout installer, et dans ce dépaquetage, impossible de retrouver le root/ du patch.

Durant l'installation du patch, ce répertoire root doit exister. Il devrait suffire d'aller voir dedans, avec un chemin relatif par rapport à celui d'un des scripts d'installation.