Re: Tech Support policy question...

>>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. 

>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?

>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.

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.

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.





On 1/29/01 2:23 PM, Jon Nolan (jon@xxxxxxxxxxx) wrote the following:

>>>isn't it monumentally obvious that enabling a
>>>virtual host for a domain that resolves to a certain IP address will cause
>>>that address to be added to the ifconfig tables?
>>Yes
>>
>>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
>
>Maybe, maybe not.  However, that's not the issue at hand.  The comment was:
>
>"...nowhere in the documentation or in the web interface was it stated that
>because of this the IP address of the host in question would be added to
>the ifconfig tables"
>
>My point is that there's no way to enable a virtual host on an IP address
>without doing the above.  Trashing Tenon because DNS is misconfigured or an
>administrative mistake was made is pointless.  What could they have done?
>Sure, the documentation could be more extensive and I've made that point
>myself.  But to piss into the wind and then blame the wind for your wet
>shoes?  Would stating the obvious in the docs have made a difference?
>
>Jon


On 1/29/01 2:03 PM, Technical Support (support@xxxxxxxxxxxxxx) wrote the 
following:

>Jason,
>
>> >isn't it monumentally obvious that enabling a
>> >virtual host for a domain that resolves to a certain IP address will cause
>> >that address to be added to the ifconfig tables?
>>Yes
>>
>>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
>
>I am not sure there is a better solution.  the options are:
>
>A script that runs at start up with the WebServer  using 
>ifconfig--This is what we do.  the server is immediately configured 
>and the IP is listed in the admin server.
>
>Edit and configure the /etc/iftab file -- clean, but would require a 
>server reboot, I believe.
>----
>Either way, the data is not 'hard coded'- it is in a plain text file.
>
>Don't get me wrong, this may not be the best for all situations-  I 
>agree that a dialog asking whether this IP should be configured is a 
>good Idea.  We will try to get this into the next admin server 
>update.  If you have other Ideas to improve the interface they are 
>certainly appreciated.
>
>Tenon Tech Support
>--Eric
>>
>>
>>
>>On 1/29/01 1:14 PM, Jon Nolan (jon@xxxxxxxxxxx) wrote the following:
>>
>> >How can a webserver possibly serve a site for which there is no IP
>> >interface?  Forgive me, but isn't it monumentally obvious that enabling a
>> >virtual host for a domain that resolves to a certain IP address will cause
>> >that address to be added to the ifconfig tables?
>> >
>> >Jon Nolan
>> >Web Dynamics, Inc.
>> >
>> >
>> >At 1:41 PM -0700 1/29/01, Stephan Wik wrote:
>> >>At 10:52 am -0800 29/1/01, Technical Support wrote:
>> >>
>> >>>This is not a bug.  It is due to misconfiguration of DNS.
>> >>
>> >>Let's be clear. There was a misconfiguration of DNS by our sysadmin.
>> >>But nowhere in the documentation or in the web interface was it
>> >>stated that because of this the IP address of the host in question
>> >>would be added to the ifconfig tables.
>> >>
>> >>The only reference I could find to the offending file was in the
>> >>technical PDF file where itools.sh is mentioned.
>> >>
>> >>I've given up on iTools so this is not such a big deal for me -
>> >>webmin and a thorough understanding of httpd.conf is turning out to
>> >>be the most robust solution. I just wanted to point out that such a
>> >>crucial aspect of hosting - i.e. the management of IP addresses - is
>> >>something that should only be done with the appropriate warnings to
>> >>the user.
>> >>
>> >>If iTools was really clever it would check the A record the CNAME
>> >>resolves to and, if it didn't point to itself, throw up an error
>> >>message. Much nicer than taking an IP that doesn't belong to it.
>> >>--
>> >>Stephan Wik                        http://www.anu.net/
>> >>ANU Internet Services         Lasso/WebCatalog Hosting
>> >>

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