Operating System - HP-UX
1753525 Members
5684 Online
108795 Solutions
New Discussion юеВ

Move workstations and servers to new network

 
MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

Gavin,

Yes, it's nice to know that other people are trying the same thing - I just wish they'd tried it first so they could warn me of the pitfalls!

The new DNS server uses DHCP but the unix systems and printers are having static ip addresses.

We're using vlans.

Mark
The triumph of evil requires only that good men do nothing
Gavin Clarke
Trusted Contributor

Re: Move workstations and servers to new network

Snap then. Although we don't use NIS.

Ah no, not quite snap, we're not moving everything right now, which complicates matters as some things will have to get back to the original network.

For printers we are changing the printer, then the switch port, then the windows queue and /etc/hosts. We are due to test this soon, the next few days.

For servers, I think you have a fair bit already, we're not moving any HPUX machines just yet.

For workstations, they should pick up the settings from the new DHCP scope once you've changed their switch ports.

DNS I think I'd be inclined to change the address, although as you can probably tell we are still very much in the planning stage.

Cheers.
Arunvijai_4
Honored Contributor

Re: Move workstations and servers to new network

The new DNS server uses DHCP but the unix systems and printers are having static ip addresses.

You may need to update the DHCP server to block the static IP addresses being allocated to any unix or print servers.

-Arun
"A ship in the harbor is safe, but that is not what ships are built for"
Chan 007
Honored Contributor

Re: Move workstations and servers to new network

Mark,
Sometime CAD applications tend to configure NFS, beware of that. Check your exports file for any IP address hardcoded.

Chan


MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

Progress so far:

Built one new workstation and added it to the new network. Made it a slave NIS server. This was successful: the workstation can see the old network and servers/workstations on the old network can see the new workstation.

Next stage: move an existing workstation on to the new network using the above workstation as its NIS master. Stages followed:

1. amend hosts file on NIS server

2. amend /etc/hosts to reflect new ip address

3. amend /etc/resolv.conf

4. amend /etc/rc.config.d/netconf

5. run set_parms initial in case I missed anything in the above steps

6. amend and reload DNS.

Result: failure. The workstation does not boot properly. I have regressed the change and reproduce below extracts from the unsuccessful rc.log. Suggestions appreciated.

Setting hostname
Output from "/sbin/rc1.d/S320hostname start":
----------------------------
/sbin/rc1.d/S320hostname[36]: nis: not found.

Configure Loopback interfaces (lo0)
Output from "/sbin/rc2.d/S008net.init start":
----------------------------
name= tcp_conn_strategy, value= 0
do_sockets_nddset() &stri= 0x7f7f0568
0

Start name server daemon
Output from "/sbin/rc2.d/S370named start":
----------------------------
/sbin/rc2.d/S370named[49]: nis: not found.
"/sbin/rc2.d/S370named start" SKIPPED

Start NIS client subsystem
Output from "/sbin/rc2.d/S420nis.client start":
----------------------------
starting NIS CLIENT networking
starting up the rpcbind
rpcbind already started, using pid: 829
domainname (correct domain name here)

starting up the Network Information Service
starting up the ypbind daemon
/usr/lib/netsvc/yp/ypbind
calling ypset with (ip address of newly built workstation here)

Sorry, ypbind on host (workstation name) has rejected your request.
Checking NIS binding.
Unable to bind to NIS server using domain (correct domain name here)
starting up the keyserv daemon
/usr/sbin/keyserv
"/sbin/rc2.d/S420nis.client start" FAILED

There are several other "nis not found" messages, but I'm sure you've got the idea by now. I ran ypinit -c to make sure the NIS hosts were correctly set but it made no difference.

Mark
The triumph of evil requires only that good men do nothing
MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

Nearly there.

I've now got a workstation successfully migrated to the new network apart from one thing - it cannot mount network filesystems.

I've bound the workstation to the one I built yesterday - a NIS slave. I logged in to the master and ran yppush auto.vol and got the reply "No response from ypxfr on ". I checked ypxfr.log on the slave and confirmed that it was not updated.

I have rerun ypinit -s on the slave and tried again - same result.

I have gone into SAM on the master and modified the list of slaves to make sure this workstation is there. I then run ypcat ypservers and it does not appear in the list.

Any ideas?

Mark
The triumph of evil requires only that good men do nothing
MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

A little nearer - I found a site that referred to /var/yp/securenets and secureservers. I've amended the files and can now transfer files from the master. But the workstation still can't see networked filesystems.

Any ideas?

Mark
The triumph of evil requires only that good men do nothing
MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

Fixed it.

I'll do another workstation tomorrow (if there's a free one), write down every stage of the process (for myself and Gavin!), then award points.

Thanks for everyone's help.

Mark
The triumph of evil requires only that good men do nothing
MarkSyder
Honored Contributor

Re: Move workstations and servers to new network

Thanks again to everyone for their help. What follows is the 10 point answer - Gavin take note!

1. Amend the ip address in /etc/hosts and add an entry for the NIS server (the master server if this box is going to be a slave, otherwise the slave server it is going to be bound to).

2. If the box is moving to a different DNS server, amend the ip address in /etc/resolv.conf

3. Amend /etc/rc.config.d/netconf - change the ip address and change the ROUTE_GATEWAY to the gateway on the new network.

4. Amend the YPBIND entry in /etc/rc.config.d/namesvrs to -ypset and put the ip address of the NIS server (master or slave as appropriate) in the YPSET_ADDR.

5. Shut the box down.

6. While it is down, ask the network administrator to change the port.

7. Amend the hosts file on the NIS server and run ypmake.

8. Amend the appropriate files on the DNS server and reload DNS.

9. Turn the box back on.

10. Assuming everything works, amend the file /etc/rc.config.d/namesvrs. Remove
-ypset and the ip address added earlier (security risk to leave them in place).

11. Run /sbin/init.d/nis.client stop and /sbin/init.d/nis.client start (and nis.server if the box is going to be a slave server - note that nis.server must be started before nis.client).

12. Check that the box is bound to the correct NIS server by typing ypwhich. Check that it has all the maps it should have by typing ypwhich -m.

It works for me - I hope it will work for the next person who finds this thread on our superb(?) search engine.

Mark
The triumph of evil requires only that good men do nothing
Gavin Clarke
Trusted Contributor

Re: Move workstations and servers to new network

Hi Mark,

You've certainly provided a whole lot of help. I'm sorry I couldn't contribute I've been a bit busy and we don't run NIS (something about paper bags).

I've realised that when we installed the HPUX machines we had the foresight to put them on the right network in the first place so it is just the Windows machines (and printers) that are migrating.

Thanks for posting all this good stuff, I'll certainly give a thorough read through a few times.

For info you can migrate the printers from your desk.

telnet or http to their IP address. Find out the MAC address which if you've got Cisco you can use to locate the switch port (show mac-address-table). Then change printer IP and default gateway, switch port then /etc/hosts and windows queue.

The tricky bits are the switch stuff.

We found that sometimes the printer needed a power cycle afterwards to get it's default gateway working.

Cheers
Gavin