nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Refreshing IWHOME

jajtiii

We are currently in the midst of implementing 3 separate TS environments, a DEV, QA and PROD. The latter two will always be in snyc, but DEV (development) will frequently get out of sync.

Is there a supported method for refreshing iw-home? We would like to be able to simply bring it back in line with QA and PROD on occasion, from a configuration standpoint.

thanks

TS 6.5, OD w/DD 6.0.1
Solaris 9

Find more posts tagged with

Comments

nipper

PUT YOUR FILES IN TEAMSITE

I have seen a bunch of implemenations (doing a 6.1 upgrade now) I see very few sites that use
a configuration branch.

DO IT

It will require a couple things. Keep your TeamSite installs in the same structure on various servers (for hardcoded paths)
Also, you will need to write a WF to approve changes and push them to $iw-home. Finally & most important, a OD script to
push from one server to another (usually dev to test to prod). However, you also need to filter out host specific files (like iw.cfg) since
they have the host name hardcoded.

The downside ? You cannot use the admin GUI since that insists on writing to iw-home, od-home, metatagger-home.

I have seen soooo many implementations and few do this. It seems so logical and it is a major help. Then I come to
my current contract and see available_templates.BAK, available_templates.OLD, etc. You have a very good version
control system. Use it. Also then you do not need to give out root/su access. OD can push the files out.

Andy

NathansDIS

I also recommend using TeamSite to manage the iw-home configuration files. However, I would strongly recommend that you make your OD script file based as opposed to teamsite area based. The config branch scheme, as set up by the IWOV consultant on our initial install, was staging area based. This worked well until some administrator directly edited the files in iw-home. Then, the next time someone in the know used the config branch in TS to publish a change, any changes made directly to the files was overwritten by the version in the config branch, and things inexplicably stopped working. (usually while I was at training ;D) Once we reworked the config branch scheme to use a file-based deployment, it has been working very well. Using TS to manage the config files does require a little more overhead and training, but it is well worth it. I have a process document for using our TS config branch to manage TeamSite if anyone wants it. Hope this helps.

-Nathan
Washington State DIS

nipper

Good to hear. What products do you use ? Any of the admin GUIs ? Not using MT Admin GUI will be a hard one to take as in 4.X it is very useful. OD GUI is a nice to have, but can live without. TS Admin GUI is almost as worthless as Smitty.

Definately agree with the file list based deployment. But when you are going from dev to test to prod, date different is your only choice.

me

NathansDIS

We use TS 6.1, OD 6 and we have a MT license, but aren't using it for anything yet. Not sure what we would actually do with MetaTagger (hoping to learn more about that at GearUp.) We do use the OD and TS admin GUIs, but as you said the TS GUI doesn't do much for us. Will probably use the OD GUI more often once IW delivers on their promise for an improved log viewer.

-n

jajtiii

Hey Nipper,

Thanks for the response.

This is actually part of an Upgrade that we are right in the middle of.

It has been our plan all along to use the DEV box to manage the config files on both the QA and PROD environments. TS workflows gave us enough functionality that we think the Change Management folks are ok with it.

BUT, the problem is with the DEV box. Are you suggesting that we create another workflow which would actually deploy to the server on which the workflow is being run? It seems very unorthodox on the face of it and what happens when DEV goes down? i.e. we muck up a cfg file, push it out (using a wft on DEV) to DEV, DEV then goes down and (since iwmnt is gone when the server is down) we can't 'revert' to a known good version.

The conundrum always circles around the fact that it would seem you always need 'another' instance to manage the 'manager', in case the manager happens to crash.....

Those are my concerns (and I hope it was clear...or at least not too muddy....)

TS 6.5, OD w/DD 6.0.1
Solaris 9

new_report.rptdesign

nipper

>BUT, the problem is with the DEV box. Are you suggesting that we create another
>workflow which would actually deploy to the server on which the workflow is being run?
>It seems very unorthodox on the face of it and what happens when DEV goes down?
> i.e. we muck up a cfg file, push it out (using a wft on DEV) to DEV, DEV then goes down and
>(since iwmnt is gone when the server is down) we can't 'revert' to a known good version.

Now few if any of your changes should *EVER* cause iwmnt to go away. However if
something were to break. that, you would have to go to iw-home and hand edit the file (hoping
that you really know what you canged)

The only times I have had to skirt the rules was when I was mucking with my email notification
script (my WF emailed me to approve other peoples changes) & the WF did not work. So I
changed the file in TS. submit-direct. Then ran OpenDeploy by hand to push the script out
to iw-home.

HTH

Andy

jajtiii

Right. I am glad that I posted this here, as it is workign some things out for me.

My worry was more that TS (and therefore iwmnt) would not come back up after our nightly backup, thanks to some cfg change we had made to DEV.

But, you are right in that I should put this into perspective (it ain't the end of the world and I'll have to make changes manually....gasp).

TS 6.5, OD w/DD 6.0.1
Solaris 9