# Rename FreeBSD Web Server



## rhyous (Apr 19, 2009)

Hey all,

I created a script to rename my FreeBSD Web Server.

See attached file.

I realize that I can rename using sysinstall, but that doesn't touch the httpd.conf file.

I thought I would post my script so others could play with it, enhance it, etc...

I would really like to see it be part of the base install someday.


----------



## rhyous (Apr 19, 2009)

I already found one important line I forgot:

hostname $1


----------



## mwatkins (Apr 21, 2009)

rhyous said:
			
		

> I would really like to see it be part of the base install someday.



Why? Do you have a specific use-case?

Changing hostnames is not something normally done with any frequency... quite often it is done once and never altered, particularly on servers, particularly where a reverse DNS entry (PTR record for the address) is also in play.


----------



## rhyous (Apr 22, 2009)

*Oh...they get renamed all too often...*

Are you guys serious?

Renaming servers is standard operation in Enterprise environments, so if it is not something that is done, then an enterprise requirement is missing.


You may say that a computer "rarely" needs to be renamed, and some of the use cases are rare, but they really aren't that rare.  Maybe rare in percentage but not in total quantity. Maybe only just under %20 of servers ever have to be renamed.  However, now look at how many servers there are (millions).


Names on servers are changed quite often.  I work for a company that sells a complex database and certificate driven server software (for windows) that unfortunately breaks if the computer is ever renamed.  One of our top call generators is how to rename the servers or they already renamed their servers and have to reinstall. (Once you are done laughing at that limitation...please proceed for use cases.)

In the corporate world, servers are renamed quite often.  Here are some reasons off the top of my head.

Use case #1 - Imaging or drive cloning
Yes most corporations build it once and clone it.  You buy 100 identical hardware servers.  
You build one server to perfection.
You then capture the drive (using and imaging utility).
You want to deploy the image and quickly change the name and IP address.
NOTE: Companies such as mine (LANDesk) and other Computer Management companies have made the imaging process very slick and have the process automatically give the computers the correct name.  We lay down the image, then mount the partition, then take steps to make the computer boot the first time with the correct new name.  This is a feature not easily done in most *nix operating systems.

Use Case 2 - New IT naming convention
You now have to comply with a standard naming convention for your servers or you had one and it just changed.

Use Case 3 - Two companies merge and they both had a dozen servers named Server1, Server2, ..., Server12.  Happens more than you think.

Use Case 4 - Providing an Appliance 
(which I am going try to do)
If you create an appliance and want to sell it, then I guess this is similar to use case 1.  Every client is going to get an appliance that has to be renamed for their company.

I could probably go on...but hopefully you understand now that in Enterprise environments, servers get renamed all the time.


----------



## rhyous (Apr 22, 2009)

Anyway...while my script is nice and works for FreeBSD OS and for Apache, it may not handle cases where the Apache name is not the same name as the host name.

Also, there needs to be way that every port, if it specifies the hostname in its configuration files, can place a script in a directory so that a single script can be called that renames the FreeBSD OS, and then runs each script in that directory to determine if it needs to update the hostname in the specific ports configuration and if so, to update it.


----------



## mwatkins (Apr 23, 2009)

I do understand the enterprise world, having come out of the big iron Unix scene and enterprise software planet too. One of our larger clients built appliances from our products. Indeed I see where you are coming from.

It was impossible to see where you were coming from in your opening post(s). Essentially you said:



> I thought I would post my script so others could play with it, enhance it, etc... I would really like to see it be part of the base install someday.



In that vague context my comment stands; I don't know about you but I find it often difficult to read minds when very little information is presented, consequently sometimes I don't bother trying.

As for "hostname", which one? A server may have multiple NICs, multiple IP's (real and aliased), each with PTR records which mean more potential hostnames.

My gut feel is that inventing infrastructure to do this one thing won't find acceptance, because "hostname" is but one parameter that might need to be considered. 

With > 20,000 ports, each of which having its own configuration approach, coming up with a common approach seems... difficult to envision.

Some orgs and companies have made a business out of *nix automation and configuration management - i.e. the popular "control panels" found in commodity web hosting environments.

In my current world hostnames don't change very often at all; and even when bringing up a new machine, the hostname data and assignment task itself is 0.0000009832% (approximately) of the data and scope of change that I might face. I have written some configuration automation software to help; and even more docs; but I find the situation still far from "press a button" ideal.


----------



## SirDice (Apr 23, 2009)

I've worked for a large insurance/banking company, had to maintain 200+ servers, names rarely changed. I currently work for a large (worldwide) oilcompany, about 6000+ servers, names rarely change..

Names rarely change because people are afraid it will break all sorts of crap. Applications with hardcoded names in them, bad I know but it happens and you have to deal with it. Even if there are no hardcoded names they still don't want it changed. 

New servers will use the new naming scheme thought up, the old servers with the old names slowly die out.. That's how I've seen it.


----------



## roddierod (Apr 23, 2009)

SirDice said:
			
		

> New servers will use the new naming scheme thought up, the old servers with the old names slowly die out.. That's how I've seen it.



I work for a world wide health provider, and this is how we also handle things. They only time a new naming convention has come along in the 11 years I have been here is when we started using blades and virtual servers. The old servers keep the old convention until they are physically moved to a new box.

The OS and base application are layed down by a ghosting. But all the webserver and database server configurations are handled by hand.


----------



## rhyous (Apr 24, 2009)

Sorry that it wasn't clear what I was saying.  

Thank you for trying to understand me.

No that I have thought this through more, thanks to some prodding from you guys, here is my idea.

1. A folder could be created called /usr/local/etc/rename.d and each port could over the course of the next few years start building a script that is able to edit their configuration files and put i the correct name.
- or - 
Either the /usr/local/etc/rc.d/appscript.sh could have a rename switch

2. The hostname command could have a switch to try to rename the box permanently.  It changes the hosts file, the rc.conf, and calls the port scripts in question.

I realize it isn't that simple.  Otherwise, I wouldn't have posted it to the community for open discussion among you who are very intelligent and savvy.


----------



## Mel_Flynn (Apr 25, 2009)

Postfix comes with postconf -e, allowing to change setting by command line. Apache has no built-in support to change settings on the fly. Numerous applications have numerous different formats.

You're trying to solve a problem that you can't solve. A much better idea would be to request devd notification for the hostname change event. Then you can plug in any script/program you like.
Or a more general devd like event notification from the OS, that isn't really "device related", but affects services.


----------

