Any Unix peeps here ?

Emp_Fab

I need to disable the DHCP server on several SCO Openserver 6 boxes.  I've managed it so far by logging in as root and running Scoadmin then blindly deleting all sorts of stuff in there and removing global settings etc.  It doesn't matter as the servers are being replaced.  I just need them to stop issuing addresses and DNS suffixes etc.  There must be a more elegant way to do it than charging in there waving an axe (metaphorically speaking !).

Sporky

Unplug the network cable? If an airgap firewall is good enough for the military...

Emp_Fab

Alas - I cannot, as the server still needs to work as a file server at that point until all the data has been copied from it.

Sporky

Darn it. I thought that might be the case.

exocet

Isn't it configured via  /etc/dhcpc.conf 

Emp_Fab

I can break it using my hatchet-man approach but I'm sure there has to be a proper way to tackle it.

digitalscream

If it helps, I believe that it's called "Address Allocation Server" in SCO Openserver. The documentation I can find only seems to give instructions on how to set it up, not kill it

digitalscream

Aha...this might work, found here:

http://uw714doc.sco.com/en/man/html.1Mtcp/aasd.1Mtcp.html

"The Address Allocation Server daemon, aasd, allocates addresses to network services, such as DHCP, which need to assign temporary addresses. It manages the information about allocated addresses, such as the service requesting the address and for how long the address is reserved.

If the configuration file (/etc/inet/aasd.conf) exists, aasd starts automatically. The configuration file defines the address pools available for allocation along with server parameters."

The bit in bold would seem to suggest that if /etc/inet/aasd.conf doesn't exist, the AAS won't start. Try renaming it to aasd.conf.old, reboot and see what happens.

Admittedly, that's for a version of Unixware from 2004, but it's the closest I could find to something relevant.

DLM

How fast does your beard grow, Emp?

digitalscream

DLM said:

How fast does your beard grow, Emp?

It's not "how fast" but rather "how far down your neck", I think

Emp_Fab

@digitalscream Cheers Lee.  I'll give that a bash.

No pun intended !

digitalscream

No worries. Given that their approach seems to be "start the server if the config file exists", if that doesn't work then I'd try renaming the dhcpc.conf as well. Might work, might not.

DLM

If not, get this guy in: https://upload.wikimedia.org/wikipedia/commons/8/81/Hans_Langseth.jpg

digitalscream

@Emp_Fab - it's worth noting that I haven't used anything by SCO since about 1998, so take my advice with a pinch of salt.

Well, SCO would probably contend that I used it every day (I'm a Linux bod), but y'know...fuck SCO. Wankers.

Jalapeno

digitalscream said:

Aha...this might work, found here:

http://uw714doc.sco.com/en/man/html.1Mtcp/aasd.1Mtcp.html

"The Address Allocation Server daemon, aasd, allocates addresses to network services, such as DHCP, which need to assign temporary addresses. It manages the information about allocated addresses, such as the service requesting the address and for how long the address is reserved.

If the configuration file (/etc/inet/aasd.conf) exists, aasd starts automatically. The configuration file defines the address pools available for allocation along with server parameters."

The bit in bold would seem to suggest that if /etc/inet/aasd.conf doesn't exist, the AAS won't start. Try renaming it to aasd.conf.old, reboot and see what happens.

Admittedly, that's for a version of Unixware from 2004, but it's the closest I could find to something relevant.

If you nobble aasd, the existing servers will need to get their shit together from somewhere - so you'll need a DHCP server running elsewhere to service their requests.

digitalscream

Jalapeno said:

digitalscream said:

Aha...this might work, found here:

http://uw714doc.sco.com/en/man/html.1Mtcp/aasd.1Mtcp.html

"The Address Allocation Server daemon, aasd, allocates addresses to network services, such as DHCP, which need to assign temporary addresses. It manages the information about allocated addresses, such as the service requesting the address and for how long the address is reserved.

If the configuration file (/etc/inet/aasd.conf) exists, aasd starts automatically. The configuration file defines the address pools available for allocation along with server parameters."

The bit in bold would seem to suggest that if /etc/inet/aasd.conf doesn't exist, the AAS won't start. Try renaming it to aasd.conf.old, reboot and see what happens.

Admittedly, that's for a version of Unixware from 2004, but it's the closest I could find to something relevant.

If you nobble aasd, the existing servers will need to get their shit together from somewhere - so you'll need a DHCP server running elsewhere to service their requests.

Fair comment...I assumed that he already had a DHCP server running somewhere (or, at the very least, has static IPs everywhere).

Jalapeno

me too, but just in case, no harm stating the bleeding obvious ....

Emp_Fab

@Jalapeno  Yes, we have another DHCP server up.  We're replacing old Unix servers that are file and DHCP servers (with a Windows DC) with new 2012 boxes.  I have to kill the DHCP service on the unix box so the 2012 box can take over, but it has to remain up temporarily whilst the data is still copying.

I worked out myself how to discover the location of the shares and how to blow open the permissions, but the way SCO handles DHCP confused me.  I stopped the AAS service and even deleted the DHCP scope, but the bloody thing was still handing out old DNS suffixes, which was playing hell with the clients.  It wasn't until I also trashed the global settings that it finally died.  I did however feel like a neanderthal clubbing it to death and I would prefer to learn how to shut it down gracefully !

Jalapeno

There's caches & timeout renewals all over the shop that would also have to play out as well - well done !

digitalscream

Emp_Fab said:

I did however feel like a neanderthal clubbing it to death and I would prefer to learn how to shut it down gracefully !

In my experience, clubbing it to death is usually the option most likely to get you the result you want in the timeframe allowed.

Another alternative would've been to fire up the new machines first, and then the old ones (thus having all the available DHCP requests already completed before the problematic servers started up).

monquixote

Do PS grep the result for aasd then kill it using the pid.

If you need to kill it after a reboot then have a look if it gets started in an init.d script and remove that.