On Aug 11, 2005, at 3:03 PM, Jeff Kell wrote: > Seeking last minute advice before blindfolding myself and stepping > off the edge... > > Current server: Listserv 1.8d / LSMTP 1.1b / Windows NT4 > > New server: Listserv 14.4 / LSMTP 1.1b / Win2K3 Server > > (A) Can this be done with some careful file migration, then just > crank it back up? Or does there need to be a step-wise update (can > you go straight 1.8d -> 14.4, or should there be an intermediate > stop?). > > (B) One stumbling block is existing lists are setup with Notebooks > on D:\PUBLIC\listname, and the new server will have them on F: > \PUBLIC\listname (it has a DVDROM in as D:). > > Any suggestions or war stories would be greatly appreciated. We've > been thinking about doing this for ages, but it is really (really) > going to happen now... The suggestion to reconfigure your new server's hardware layout makes sense. You'll save yourself a lot of effort by avoiding the need to make any changes in the path on each list's Notebook keyword. I had to do a more complicated migration last January. I went from Listserv 1.8d under a cranky old Tru64 Unix system to Listserv 14.3 under Red Hat Linux with a completely different file system and different mail distribution agent. I also migrated a small Listserv 1.8e server from Windows 2000 to our Listserv 14.3 server after I finished with our primary Listserv 1.8d server's migration. I migrated the list's from the Windows server individually over a period of about one month and I notified each list owner as I worked through that migration. The migration of our Listserv 1.8d server was urgently needed because our old Listserv crashed every night like clockwork. To migrate the 1600+ Listserv 1.8d lists, I wrote some perl scripts. One perl script transferred all but the most recent archives files for each list from our old Listserv 1.8d server to our new one. The script worked by creating a tar file for each list's old log files. I knew I could run that script safely while the Listserv was in production because the old archive files could not change. I ran that script a few days prior to the cutoff date for our migration and I transferred the tar files to our new server and I untarred them. I also wrote a script to transfer the lists and I did that before the cut-off date just to make sure everything worked. I also needed a script to generate the multiple sendmail aliases that each list uses because we moved from qmail to sendmail at the same time, which was against my recommendation. Everything worked fine. I was able to start up the new Listserv and have it index the archive files and I could do all the usual Listserv type stuff via the wa CGI. I also set up some test lists on our old server to try out during this process, so I could be sure my migration method was sound. On the actual migration day, all I had to do was run another perl script to migrate the most recent log files over. I also wrote another perl script that created a tar file for each list that consisted of the .list file, plus any .mailtpl and other support files. That script also adjusted each list's Notebook keyword to reflect the different path each list's log files needed. As a result, on the actual migration day, all I had to do was shut down our old Listserv 1.8d server, move the most recently changed files over, plus the list's support files. Half an hour later,we were good to go, but I did have one glitch which was out of my control that delayed the time I was able to begin the final migration phase. If you can, I suggest you move the IP address and host name over from your Listserv 1.8d server to your 14.4 server. This will make your life a lot easier if your relationship with the people who maintain your organization's DNS is not as good as it should be. The only glitch I had that gave me any grief involved a DNS change. We were in a situation here where we had to move the listserv.temple.edu host name from one IP address to another for reasons that don't matter here. At least two weeks prior to our migration date, I requested that our Network Services group make this change on the migration date at a specific time.. Unfortunately, that time came and went despite my reminding our DNS gate keepers repeatedly that this change was crucial to the project, but they had other ideas. After my pleas went unheeded, I finally had to enlist the help of senior management to coax our network people into making the DNS change. As a result of this delayed DNS change, the new IP address did not propagate to the computers at our help desk on a timely basis. It took a few hours for some reason for the change to propagate to our help desk area. This delay caused a great deal of confusion for Temple's help desk staff. Oddly enough, the change propagated everywhere else much faster, including to the two workstations in my office so I didn't realize this was an issue until I started getting complaints from help desk consultants. The moral of my story is, you would be wise to keep the same IP address and host name on your new Listserv. Of course, you'll need to shut down the old Listserv server to ensure you do not have an IP address conflict. Eight months has passed since I did that migration and we still have all the old lists sitting around on our old server (which also received a new host name). Had my migration plan failed, I would have simply brought the old server back online with its old host name and returned to the drawing board to develop a better migration plan, but fortunately, it worked well. Now, I am getting ready to migrate from Listserv 14.3 to 14.4 this Tuesday, and I am looking forward to completing that process. By the way, you do realize you need a new 14.4 LAK, right? This is explained in the documentation. If you haven't requested a new LAK, I suggest you do so now.