Re: Tech Support policy question...

I will go over this again so there is no question as to what to do in this event:

>>isn't it monumentally obvious that altering any address that was added to

the ifconfig tables should be performed in an other way than hacking a
tennon script that hard codes data onto its self?
Yes

My point is that there's no way to disable a virtual host on an IP address
without doing the above.

This is not true. You should delete the offending virtual host in the admin server. The admin server will delete the offending ifconfig line and take it out of the tables. Problems occur when users manually edit the httpd.conf file in this case.

so:

If the IP address does not look correct for the server, delete the virtual host and fix the DNS.

Yes- this should be documented. I will put it in the FAQ right now.

>Edit and configure the /etc/iftab file -- clean, but would require a
server reboot, I believe.
I believe there is no need to edit the /etc/iftab file because when the
restored iTools.sh file launches the program the next time it does it for
you no?

I was giving options as to what the admin server could possibly do instead of using an ifconfig script

the only option would be to use iftab and get rid of iTools.sh

 >Either way, the data is not 'hard coded'- it is in a plain text file.
iTools.sh is a (cleartext) script no?
Anyone can make that mistake and have no web based recourse when it
happens.  There are risks for begining users attempting to restore the
iTools.sh file themselves. I suspect it's not Tenon's intention for
endusers to edit, and risk supporting the incident where mistakenly
iTools.sh was uploaded back as a binary or worse.

The point is that there is a Web Based recourse. Delete the virtual host in the admin server. the problems occur- as you mentioned, when users start editing files without understanding the ramifications.

I think its safe to say we would all enjoy an elegant way to restore the
iTools.sh file in the situation it takes over the ip of another computer.
Regardless in my oppinion if tenon in fact does choose to update the
iTools docs to include instructions on what to do if this were to happen.

Simply someone/tenon could just write a little script that would
restore/allow interaction with the iTools.sh file's use of storing the
list of the local server's aditional ips.

The admin server does this already

It's a great feature having iTools add aditional ips for us, yes it is!
And with that, another feature has now reared its head and clearly it can
save everyone's time in the end.

I think the warning dialog is the best idea and will probably be implemented in the final iTools 6.0 and iTools 5.0x update

Tenon Tech Support
--Eric

----
Tenon Intersystems' iTools Mailing List
To unsubscribe: send mail to itools-request@xxxxxxxxx
with the subject: unsubscribe