Re: Migration TeX/LaTeX: from teTeX -- TeXlive
On Mon, Sep 16, 2013 at 01:57:51AM +0200, Polytropon wrote: On Sun, 15 Sep 2013 21:00:22 +0200, Roland Smith wrote: Personally I don't think TeX is a good fit for the ports tree (because of duplication of effort). I have to add that I think that the chosen strategy (provide a full port and a minimal port) is a good balance between functionality and maintenance workload. In conclusion, that could be said about many other software that brings its own package management. More or less. Not all of those work equally well as tlmgr or the ports tree. Of course, LaTeX is a big and complex beast that TeXLive manages well (instead of the system-provided tools for managing the ports tree). In my opinion, a good _integration with_ the ports tree is important, so dependencies will be resolved properly (and you won't end up havong both TeXLive _and_ teTeX on your system for no particular need). The problem is that if you hand over the management of the TeXLive install to tlmgr, the ports tree doesn't know and cannot know what is provided and what is depended on... On the other hand, this might introduce demands of other software compilations to move their management out of the system's range, so we end up micro-managing many different sets of software in their own specific way, abandoning the centralized means of maintaining our software... There is indeed no silver bullet. Since TeXLive is very complete and self-contained, I don't have other ports that depend on TeX. It's the port maintainers' task to take care of the proper declaration of dependencies, and for system tools to handle them. I don't think it is a big problem to make this consistent with how TeXLive handles things. It is not that simple. After every tlmgr run, you'd have to generate a new plist for the port. Since TeXLive is contained in one directory tree (/usr/local/texlive/year) that part is relatively simple. But tlmgr can also install scripts or binaries. So after every tlmgr run, the list of binaries that the port provides and the list of libraries or interpreters (ports) that it requires would have to be updated. This is not trivial. And if you ever run tlmgr outside of the port Makefile, the installed port's information must be assumed to be out of date. Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpr0OQulLtEk.pgp Description: PGP signature
Re: Migration TeX/LaTeX: from teTeX -- TeXlive
On Mon, 16 Sep 2013 20:33:15 +0200, Roland Smith wrote: On Mon, Sep 16, 2013 at 01:57:51AM +0200, Polytropon wrote: On Sun, 15 Sep 2013 21:00:22 +0200, Roland Smith wrote: Personally I don't think TeX is a good fit for the ports tree (because of duplication of effort). I have to add that I think that the chosen strategy (provide a full port and a minimal port) is a good balance between functionality and maintenance workload. This is a good approach for all cases where no custom configuration (being done by tlmgr) has been done, and it should work for most scenarios, I assume. In conclusion, that could be said about many other software that brings its own package management. More or less. Not all of those work equally well as tlmgr or the ports tree. Of course; think about pip, npm, and the like. The preferred goal of using tlmgr from the TeXLive distribution instead of installing it with the ports tree (or pkg) would be that it somehow at least records the existence of the TeXLive installation on the system. This causes ports depending on it _not_ to attempt any futile additional installation. Of course, LaTeX is a big and complex beast that TeXLive manages well (instead of the system-provided tools for managing the ports tree). In my opinion, a good _integration with_ the ports tree is important, so dependencies will be resolved properly (and you won't end up havong both TeXLive _and_ teTeX on your system for no particular need). The problem is that if you hand over the management of the TeXLive install to tlmgr, the ports tree doesn't know and cannot know what is provided and what is depended on... Correct. As I said, I'd suggest tlmgr could honor that case if it is run on FreeBSD and update the system records accordingly, so port management and pkg can work with that foreign installation as if it would have been a valid installation done with the system's default means. On the other hand, this might introduce demands of other software compilations to move their management out of the system's range, so we end up micro-managing many different sets of software in their own specific way, abandoning the centralized means of maintaining our software... There is indeed no silver bullet. True. However, a good integration with keeping an eye on the most obvious and important side effects could help. For example, the TEX_DEFAULT setting in /etc/make.conf is already a good beginning to select between teTeX and TeXLive. Maybe something similar could be added by tlmgr to satisfy port and package management tools with the illusion that everything went fine? :-) Since TeXLive is very complete and self-contained, I don't have other ports that depend on TeX. It's the port maintainers' task to take care of the proper declaration of dependencies, and for system tools to handle them. I don't think it is a big problem to make this consistent with how TeXLive handles things. It is not that simple. After every tlmgr run, you'd have to generate a new plist for the port. Since TeXLive is contained in one directory tree (/usr/local/texlive/year) that part is relatively simple. But tlmgr can also install scripts or binaries. So after every tlmgr run, the list of binaries that the port provides and the list of libraries or interpreters (ports) that it requires would have to be updated. This is not trivial. I recognize that complicated task, but I would like to say that solving that problem (or at least possible annoyance) would really benefit both worlds - TeXLive can be managed with tlmgr _and_ the system software records will keep working properly. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration TeX/LaTeX: from teTeX -- TeXlive
On Sat, Sep 14, 2013 at 02:22:12PM +0200, O. Hartmann wrote: I use for my day to day work teTeX, but I run more and more into several limitations due to the fact, teTeX isn't any more (and regretably) maintained/developed by Th. Esser (that is what I know). Upstream teTeX has indeed been deprecated in favor of TeXLive. Well, TeXlive is now in the ports tree, but I had recently on a server, on which I tried to migrate, massive problems with the most recent CURRENT, where gcc is completely gone (luckily) and converters/iconv has been removed. I can not clearly say what causes the problems, since there seem to be remains of teTeX in the system, but they are needed for some essential facilities and I do not dare ripping them off. Was your machine updated from 9.x to CURRENT? In that case you should really remove _all_ ports and re-install them. That is the only way to get rid of old junk when switching to a new major version. Before I start time consuming experiments, I'd like to ask whether there is a smooth way of migration. And for that, please enlighten me how I can extract those ports installed and needed by teTeX (a kind of port-traceback of required ports) and delete them, as far as they do not share common being required by xxx port, too. Personally I don't think TeX is a good fit for the ports tree (because of duplication of effort). I installed TeXLive using its own installer long before it was present in the ports tree. Since TeXLive is very complete and self-contained, I don't have other ports that depend on TeX. I am certain that TeXLive has pre-built binaries for FreeBSD 9, but I don't know about CURRENT. To see which ports require (parts of) teTeX, use `pkg_info -Rx tetex` Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpwUlqhM9g4C.pgp Description: PGP signature
Re: Migration TeX/LaTeX: from teTeX -- TeXlive
On 09/15/2013 02:00 PM, Roland Smith wrote: Personally I don't think TeX is a good fit for the ports tree (because of duplication of effort). I installed TeXLive using its own installer long before it was present in the ports tree. Since TeXLive is very complete and self-contained, I don't have other ports that depend on TeX. +1 My TeX dependency and maintenance problems all but disappeared when I moved to the freestanding TeXLive installation. I run a nightly cron job to get the latest updates via tlmgr and it works like a charm. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration TeX/LaTeX: from teTeX -- TeXlive
On Sun, 15 Sep 2013 21:00:22 +0200, Roland Smith wrote: Personally I don't think TeX is a good fit for the ports tree (because of duplication of effort). In conclusion, that could be said about many other software that brings its own package management. Of course, LaTeX is a big and complex beast that TeXLive manages well (instead of the system-provided tools for managing the ports tree). In my opinion, a good _integration with_ the ports tree is important, so dependencies will be resolved properly (and you won't end up havong both TeXLive _and_ teTeX on your system for no particular need). On the other hand, this might introduce demands of other software compilations to move their management out of the system's range, so we end up micro-managing many different sets of software in their own specific way, abandoning the centralized means of maintaining our software... I installed TeXLive using its own installer long before it was present in the ports tree. It should maybe be possible (and encouraged?) to use a concept like using the ports tree for invoking the TeXLive custom installer, so you don't have to manually download and extract stuff, a simple make install from the ports tree would do that for you. However, the TeXLive installer co-operates well with FreeBSD, so it's not a big problem to get TeXLive installed and running. Since TeXLive is very complete and self-contained, I don't have other ports that depend on TeX. It's the port maintainers' task to take care of the proper declaration of dependencies, and for system tools to handle them. I don't think it is a big problem to make this consistent with how TeXLive handles things. I am certain that TeXLive has pre-built binaries for FreeBSD 9, but I don't know about CURRENT. It would be even more greaterer to have pkg add texlive working, performing the download, and installing the FreeBSD binaries and libraries as needed, while keeping the system records intact. :-) To see which ports require (parts of) teTeX, use `pkg_info -Rx tetex` Plus `pkg_info -Rx teTeX` because of the way it is spelled. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Migration TeX/LaTeX: from teTeX -- TeXlive
I use for my day to day work teTeX, but I run more and more into several limitations due to the fact, teTeX isn't any more (and regretably) maintained/developed by Th. Esser (that is what I know). Well, TeXlive is now in the ports tree, but I had recently on a server, on which I tried to migrate, massive problems with the most recent CURRENT, where gcc is completely gone (luckily) and converters/iconv has been removed. I can not clearly say what causes the problems, since there seem to be remains of teTeX in the system, but they are needed for some essential facilities and I do not dare ripping them off. Before I start time consuming experiments, I'd like to ask whether there is a smooth way of migration. And for that, please enlighten me how I can extract those ports installed and needed by teTeX (a kind of port-traceback of required ports) and delete them, as far as they do not share common being required by xxx port, too. Please CC me, I'm not subscribing this list. Regards and thanks, Oliver Hartmann signature.asc Description: PGP signature
i386 to amd64 migration
Hello, I have experience in freebsd but never did such system architecture migration. Is it possible to do safely with only SSH access (or IP-KVM)? I'm planning to upgrade system from 7.2 to 7.3 but it's i386.. Regards, Elifan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: i386 to amd64 migration
AFAIK,basically no x86 - x86 and x64 - x64 Non-basically ... yes but it's a real pain in the @$$ and you will definitely run in all kinds of trouble. ip you have KVM access, just put a x64 DVD inside and do a clean install (it will keep your sanity intact) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
7.0/i386 to 8.0/amd64 - gmirror/gstripe migration
Hi! I am planning to move from 7.0-REL-i386 to 8.0-REL-amd64 in the near future. My OS drive is a single ata-133 80gb drive, and my data drives are four 1.5TB SATA drives. 6TB total, configured as 2x 3TB 'gstripe' volumes, and I am using gmirror to mirror those gstripe volumes. I hope that makes sense. In any case, I'd like to just unplug the drives, do my upgrade, plug the drives back in, and startup the array as I have in 7.0.I'm planning to just do a fresh install of 8.0 on a new SATA 80GB drive and make that my new OS drive. Does anyone foresee any serious problems with this plan? I know doing a whole version upgrade can sometimes introduce bugs when dealing with old setups, so I just want to cover my bases prior to the work. I am backing up this system to another system, so if I end up losing the data or having to rebuild the array, that's fine, it just sucks having to copy the 2TB of data over the wire afterward. Thanks for your help! ++AMARU ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 7.0/i386 to 8.0/amd64 - gmirror/gstripe migration
No one has any idea? :( ++AMARU From: Amaru Netapshaak postfix_am...@yahoo.com To: freebsd-questions@freebsd.org Sent: Wed, May 19, 2010 9:33:14 AM Subject: 7.0/i386 to 8.0/amd64 - gmirror/gstripe migration Hi! I am planning to move from 7.0-REL-i386 to 8.0-REL-amd64 in the near future. My OS drive is a single ata-133 80gb drive, and my data drives are four 1.5TB SATA drives. 6TB total, configured as 2x 3TB 'gstripe' volumes, and I am using gmirror to mirror those gstripe volumes. I hope that makes sense. In any case, I'd like to just unplug the drives, do my upgrade, plug the drives back in, and startup the array as I have in 7.0.I'm planning to just do a fresh install of 8.0 on a new SATA 80GB drive and make that my new OS drive. Does anyone foresee any serious problems with this plan? I know doing a whole version upgrade can sometimes introduce bugs when dealing with old setups, so I just want to cover my bases prior to the work. I am backing up this system to another system, so if I end up losing the data or having to rebuild the array, that's fine, it just sucks having to copy the 2TB of data over the wire afterward. Thanks for your help! ++AMARU ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 7.0/i386 to 8.0/amd64 - gmirror/gstripe migration
Hi! I am planning to move from 7.0-REL-i386 to 8.0-REL-amd64 SNIP! Does anyone foresee any serious problems with this plan? I know doing a whole version upgrade can sometimes introduce bugs when dealing with old setups, so I just want to cover my bases prior to the work. This sounds like the kind of thing Release notes were designed for. I was not able to find them on the first page of the FreeBSD website, but if you click the big Get FreeBSD Now button, there is a link in the table detailing the releases: http://www.freebsd.org/releases/8.0R/relnotes.html I am backing up this system to another system, so if I end up losing the data or having to rebuild the array, that's fine, it just sucks having to copy the 2TB of data over the wire afterward. Good idea ;) FreeBSD no longer supports dangerously dedicated UFS filesystems (section 2.2.5 of Detailed release notes) but I'm not sure if that is possible with gmirror. Thanks for your help! ++AMARU PS: Your reply to yourself was in the same digest message. Not everybody is in your timezone either. Regards, James Phillips ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 7.0/i386 to 8.0/amd64 - gmirror/gstripe migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/05/2010 24:03:17, Amaru Netapshaak wrote: I am planning to move from 7.0-REL-i386 to 8.0-REL-amd64 in the near future. My OS drive is a single ata-133 80gb drive, and my data drives are four 1.5TB SATA drives. 6TB total, configured as 2x 3TB 'gstripe' volumes, and I am using gmirror to mirror those gstripe volumes. I hope that makes sense. Errr... the usual way of doing this is to create mirrored pairs of drives and then stripe the mirrors together (a.k.a RAID10 -- creating a pair of stripes and then mirroring them is RAID0+1). There's very little difference in performance characteristics between the two, but RAID10 is more failure resistant. Think about what happens if you lose one drive. In the RAID10 case one mirror pair runs in degraded mode. In the RAID0+1 case, one stripe -- half of your drives -- is out of action. In any case, I'd like to just unplug the drives, do my upgrade, plug the drives back in, and startup the array as I have in 7.0.I'm planning to just do a fresh install of 8.0 on a new SATA 80GB drive and make that my new OS drive. Should be fine. I've done source upgrades from 7.x to 8.0 and gmirror has just worked. If your old 7.0 drive is still in decent working order, it might be an idea to set up the new 8.0 drive as half of a gmirror, and then reuse the 7.0 drive as the other half once you're happy that the upgrade succeeded. If the disks aren't identical, you'll need to make sure that the new 8.0 disk is not bigger than the old 7.0 drive -- look at the number of sectors on each disk for the best comparison. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv0y14ACgkQ8Mjk52CukIxK6wCdE9AEVBJbvT3IjT3CWpcYaam4 mk0An03OU96lPTtF7VigcT976Qr1ssdf =3yzZ -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On Sat, Jan 23, 2010 at 11:35:20PM -0800, Doug Hardie wrote: On 23 January 2010, at 22:42, John wrote: On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote: Hi, On 24 January 2010 am 01:08:27 John wrote: doing this on a new machine! And I don't need any migration storage, because, well, gosh - it's tcp, people! ;) I just did the first transfer of home, and it went swell: how did you handle the strange group IDs? Have not done that yet. My current best plan (which I'm not really crazy about, but haven't come up with anything better) is to do 121 find /home -uid ... -exec chown {} + and 37 find /home -gid ... -exec chgrp {} + commands. This is also called Let's modify every inode in the filesystem. Twice. Oh, well, the ctimes are blown up by the migration anyway (as they really should be). I have to be careful, if there are any IDs that are used on both systems, but with different associations, to do the change in the right order (sigh). I could try to get really fancy and just find the distinct combinations of uid:gid and do only one chown uid:gid for each file, but, getting it done will be more important than being pretty at some point. You might check out tar. At one time it had the option to use user and group names and not ids. Hence the ids could change between the 2 systems. It seems like it was on FreeBSD 3 or 4 that I last did that. I just tried it with FreeBSD 7.2 creating a tar file. Digging through the file it shows the ascii names for owner and group - not uid/gid. I un-tar'd it on a Mac and sure enough it used the names and the uids are quite different for the two systems. Well, that would just serve me right after dissing tar in favor of dump/restore earlier in this thread, now wouldn't it? I think you can preserve the mtimes, too, if I recall correctly. The reason that I don't want to do this, though, is that I don't believe there's anyway to preserve the atime on either system. The last access time of every file in the file system would be when I did the migration (because tar is reading the files through the filesystem, rather than reading the file system structure on the disk, like dump does), rather than when they were really last used. -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
Hi, On 24 January 2010 pm 14:42:11 John wrote: On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote: how did you handle the strange group IDs? Have not done that yet. My current best plan (which I'm not really crazy about, but haven't come up with anything better) is to do 121 find /home -uid ... -exec chown {} + and 37 have you ever thought that it does not really matter as you have control over the group file. You can leave your strange group IDs but you must maintain your group file by hand. You might have to check it after each new software installation but for the operation for machine, it should not matter. And, of course, there's the whole matter of migrating the passwords... This I never did. It probably is, but I see so much of other servers running on similar hardware with a certain other operating system that have a reguluar 30-day scheduled reboot, it still delights me. I just wanted to share my delight! Is it a Tuesday? Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
Hi, On 24 January 2010 pm 15:35:20 Doug Hardie wrote: On 23 January 2010, at 22:42, John wrote: I just tried it with FreeBSD 7.2 creating a tar file. Digging through the file it shows the ascii names for owner and group - not uid/gid. I un-tar'd it on a Mac and sure enough it used the names and the uids are quite different for the two systems.___ what happens if you first create the user names on the target system and then open the archive? It would be then very easy to move files accross systems. I never have had to do this. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote: Hi, On 23 January 2010 am 01:12:19 John wrote: Now that I've actually gotten the new system to boot, I need to figure out how I'm going to migrate everything - users, data, MySQL, NAT, firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc from FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004 to FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 this is real jump. Bit of a challenge, eh? I have heard that somebody actually landed on the moon? Was it you? Not only that, but I'd like to update my UID scheme from a pre-standard version (most of the UIDs are down in the 100s) to the new convention so that I'm more in-line with the rest of the world. Ok, I cannot imagine how you will do this with the access rights of the files? My rough idea: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up Are you sure? Use /usr to make sure you will have enough space. You are making the rash and probably incorrect assumption that /usr is the largest partition/filesystem. Many people, including I, make /home or another partition be the large one. The OP may also have done that. 2) Start putting together all the pieces - trying to find update / conversion scripts whenever possible. I think, this would only help if you would go the long way 5.x, 6.x, 7x and finally 8. Setup the new machine, install the applications you need, configure them as close as possible to the original configuration and see what happens. 4) Let people move in, try it out, see how things are 5) Fix everything found in #4 6) Try a cut-over and make sure all the network services work in the middle of the night sometime, then switch back Oh, it is a life system in use while you migrate. Are you able to set the new thing up in parallel? It might be easier for you to run both machines and move first the simple things over. 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch Move/migrate them first. Don't make assumptions about what the OP has on /home. But, I agree, if possible, use a second machine with V 8.0 installed and migrate to it. Otherwise, make full backups, check them for readability. Then do a new install of FreeBSD V8. Add a large disk and pull stuff out of your dump to it and then migrate that stuff piece by piece back to the machine main filesystems. jerry 9) spend a couple of weeks fixing all the things that weren't so disastrous that they got picked up in #4. I think, if you do it service by service, you have a better chance to avoid this. Ideas / scripts / project plans / outlines - whatever? Maybe I should write a chapter for The Complete FreeBSD after surviving this... Yes. It is a Le Must. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On Sat, Jan 23, 2010 at 11:19:34AM -0500, Jerry McAllister wrote: On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote: Hi, On 23 January 2010 am 01:12:19 John wrote: Now that I've actually gotten the new system to boot, I need to figure out how I'm going to migrate everything - users, data, MySQL, NAT, firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc from FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004 to FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 this is real jump. Bit of a challenge, eh? I have heard that somebody actually landed on the moon? Was it you? Not only that, but I'd like to update my UID scheme from a pre-standard version (most of the UIDs are down in the 100s) to the new convention so that I'm more in-line with the rest of the world. Ok, I cannot imagine how you will do this with the access rights of the files? My rough idea: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up Are you sure? Use /usr to make sure you will have enough space. You are making the rash and probably incorrect assumption that /usr is the largest partition/filesystem. Many people, including I, make /home or another partition be the large one. The OP may also have done that. 2) Start putting together all the pieces - trying to find update / conversion scripts whenever possible. I think, this would only help if you would go the long way 5.x, 6.x, 7x and finally 8. Setup the new machine, install the applications you need, configure them as close as possible to the original configuration and see what happens. 4) Let people move in, try it out, see how things are 5) Fix everything found in #4 6) Try a cut-over and make sure all the network services work in the middle of the night sometime, then switch back Oh, it is a life system in use while you migrate. Are you able to set the new thing up in parallel? It might be easier for you to run both machines and move first the simple things over. 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch Move/migrate them first. Don't make assumptions about what the OP has on /home. But, I agree, if possible, use a second machine with V 8.0 installed and migrate to it. Otherwise, make full backups, check them for readability. Then do a new install of FreeBSD V8. Add a large disk and pull stuff out of your dump to it and then migrate that stuff piece by piece back to the machine main filesystems. jerry 9) spend a couple of weeks fixing all the things that weren't so disastrous that they got picked up in #4. I think, if you do it service by service, you have a better chance to avoid this. Ideas / scripts / project plans / outlines - whatever? Maybe I should write a chapter for The Complete FreeBSD after surviving this... Yes. It is a Le Must. Erich Sorry, gang - I should have been more clear! I am DEFINITELY doing this on a new machine! And I don't need any migration storage, because, well, gosh - it's tcp, people! ;) I just did the first transfer of home, and it went swell: On elwood (the new, 8.0 system): cd / umount /home newfs /dev/ad0s3e mount /home cd /home rsh dexter dump 0uf - /home | restore rvf - That preserves all the file modification times, too, even on directories. All you young'uns out there - don't forget dump/restore! tar and cpio are nice, but sometimes, you just gotta take it all... (dexter is the old machine - the FreeBSD 4.3 system) Oh, BTW, just for giggles: 10:56AM up 492 days, 13:57, 2 users, load averages: 0.02, 0.03, 0.00 That's right! Nearly 500 days! And it was well over a two hundred days before that, but we had a power outage that outlasted the UPS. Gotta love this stuff! Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll rl0 1500 Link#100:40:f4:8e:37:c7 384602213 1 585428419 0 0 rl0 1500 192.168.1 gateway 56160554 - 40918536 - - rl0 1500 dexter/32 dexter246146 -0 - - ed0 1500 Link#252:54:40:21:f8:a8 609350703 376495 380734152 0 15678720 ed0 1500 XXmaskedXXxxMASKEDx x 63482137 - 380606442 - - lo0 16384 Link#3 27069210 0 27069210 0 0 lo0 16384 127 localhost 27069192 - 27069192 - - 987522505 cpu context switches 2590296969 device interrupts 342786031 software interrupts 1096125243 traps 1217705867 system calls 4 kernel threads created 12006286 fork() calls 429899 vfork() calls 0 rfork() calls 954 swap pager pageins 1156 swap pager pages paged in 456 swap pager pageouts 774 swap pager
Re: Migration planning - old system to new
Hi, On 24 January 2010 am 00:19:34 Jerry McAllister wrote: On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote: On 23 January 2010 am 01:12:19 John wrote: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up Are you sure? Use /usr to make sure you will have enough space. You are making the rash and probably incorrect assumption that /usr is the largest partition/filesystem. Many people, including I, make /home or another partition be the large one. The OP may also have done that. so true. It might be easier for you to run both machines and move first the simple things over. 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch Move/migrate them first. Don't make assumptions about what the OP has on /home. This was written by him not me. But, I agree, if possible, use a second machine with V 8.0 installed and migrate to it. Otherwise, make full backups, check them for readability. Then do a new install of FreeBSD V8. Add a large disk and pull stuff out of your dump to it and then migrate that stuff piece by piece back to the machine main filesystems. It sounds to me that his main problem is that it is a life system and he wants to avoid down-time. Not this easy. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
Hi, On 24 January 2010 am 01:08:27 John wrote: doing this on a new machine! And I don't need any migration storage, because, well, gosh - it's tcp, people! ;) I just did the first transfer of home, and it went swell: how did you handle the strange group IDs? 10:56AM up 492 days, 13:57, 2 users, load averages: 0.02, 0.03, 0.00 Isn't this normal for a FreeBSD machine running as a server? That's right! Nearly 500 days! And it was well over a two hundred days before that, but we had a power outage that outlasted the UPS. No diesel powered generator nearby? 987 522 505 cpu context switches I have had to put the spacesin to be able to read it. I assume, the scheduler really works. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote: Hi, On 24 January 2010 am 01:08:27 John wrote: doing this on a new machine! And I don't need any migration storage, because, well, gosh - it's tcp, people! ;) I just did the first transfer of home, and it went swell: how did you handle the strange group IDs? Have not done that yet. My current best plan (which I'm not really crazy about, but haven't come up with anything better) is to do 121 find /home -uid ... -exec chown {} + and 37 find /home -gid ... -exec chgrp {} + commands. This is also called Let's modify every inode in the filesystem. Twice. Oh, well, the ctimes are blown up by the migration anyway (as they really should be). I have to be careful, if there are any IDs that are used on both systems, but with different associations, to do the change in the right order (sigh). I could try to get really fancy and just find the distinct combinations of uid:gid and do only one chown uid:gid for each file, but, getting it done will be more important than being pretty at some point. Open to suggestions! (I'd generate the commands via a script, of course.) And, of course, there's the whole matter of migrating the passwords... 10:56AM up 492 days, 13:57, 2 users, load averages: 0.02, 0.03, 0.00 Isn't this normal for a FreeBSD machine running as a server? It probably is, but I see so much of other servers running on similar hardware with a certain other operating system that have a reguluar 30-day scheduled reboot, it still delights me. I just wanted to share my delight! That's right! Nearly 500 days! And it was well over a two hundred days before that, but we had a power outage that outlasted the UPS. No diesel powered generator nearby? No - though this system does real work - it is actually located in my home. It probably isn't unusual for data center machines, except those that are on some sort of regular uptick upgrade schedule. 987 522 505 cpu context switches I have had to put the spacesin to be able to read it. I assume, the scheduler really works. So it would seem! Erich -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On 23 January 2010, at 22:42, John wrote: On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote: Hi, On 24 January 2010 am 01:08:27 John wrote: doing this on a new machine! And I don't need any migration storage, because, well, gosh - it's tcp, people! ;) I just did the first transfer of home, and it went swell: how did you handle the strange group IDs? Have not done that yet. My current best plan (which I'm not really crazy about, but haven't come up with anything better) is to do 121 find /home -uid ... -exec chown {} + and 37 find /home -gid ... -exec chgrp {} + commands. This is also called Let's modify every inode in the filesystem. Twice. Oh, well, the ctimes are blown up by the migration anyway (as they really should be). I have to be careful, if there are any IDs that are used on both systems, but with different associations, to do the change in the right order (sigh). I could try to get really fancy and just find the distinct combinations of uid:gid and do only one chown uid:gid for each file, but, getting it done will be more important than being pretty at some point. You might check out tar. At one time it had the option to use user and group names and not ids. Hence the ids could change between the 2 systems. It seems like it was on FreeBSD 3 or 4 that I last did that. I just tried it with FreeBSD 7.2 creating a tar file. Digging through the file it shows the ascii names for owner and group - not uid/gid. I un-tar'd it on a Mac and sure enough it used the names and the uids are quite different for the two systems.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Migration planning - old system to new
Now that I've actually gotten the new system to boot, I need to figure out how I'm going to migrate everything - users, data, MySQL, NAT, firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc from FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004 to FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 Bit of a challenge, eh? Not only that, but I'd like to update my UID scheme from a pre-standard version (most of the UIDs are down in the 100s) to the new convention so that I'm more in-line with the rest of the world. My rough idea: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up 2) Start putting together all the pieces - trying to find update / conversion scripts whenever possible. 3) once things get close, do the dump/retore of home, and a tar/untar of /var/mail (since I'm moving it from a part of the /var filesystem to a filesystem of its own - doing a dump/restore on /var is not a practical migration strategy in any case) 4) Let people move in, try it out, see how things are 5) Fix everything found in #4 6) Try a cut-over and make sure all the network services work in the middle of the night sometime, then switch back 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch 9) spend a couple of weeks fixing all the things that weren't so disastrous that they got picked up in #4. Ideas / scripts / project plans / outlines - whatever? Maybe I should write a chapter for The Complete FreeBSD after surviving this... -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
On 22 January 2010, at 09:12, John wrote: Now that I've actually gotten the new system to boot, I need to figure out how I'm going to migrate everything - users, data, MySQL, NAT, firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc from FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004 to FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 Bit of a challenge, eh? Not only that, but I'd like to update my UID scheme from a pre-standard version (most of the UIDs are down in the 100s) to the new convention so that I'm more in-line with the rest of the world. My rough idea: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up 2) Start putting together all the pieces - trying to find update / conversion scripts whenever possible. 3) once things get close, do the dump/retore of home, and a tar/untar of /var/mail (since I'm moving it from a part of the /var filesystem to a filesystem of its own - doing a dump/restore on /var is not a practical migration strategy in any case) 4) Let people move in, try it out, see how things are 5) Fix everything found in #4 6) Try a cut-over and make sure all the network services work in the middle of the night sometime, then switch back 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch 9) spend a couple of weeks fixing all the things that weren't so disastrous that they got picked up in #4. Ideas / scripts / project plans / outlines - whatever? Maybe I should write a chapter for The Complete FreeBSD after surviving this... I presume you can't bring down the old system for a few weeks to make the conversion. Thus I would suggest you get the new system configured the way you want without the user data and back it up so that you can restore it to that configuration easily. Then once you have your approach established do a test conversion. Leave the old system in production and check out the results of the conversion. You may want to tweak your conversion approach a few times. Then when it works fine, restore the new system and do the conversion for real.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration planning - old system to new
Hi, On 23 January 2010 am 01:12:19 John wrote: Now that I've actually gotten the new system to boot, I need to figure out how I'm going to migrate everything - users, data, MySQL, NAT, firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc from FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004 to FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 this is real jump. Bit of a challenge, eh? I have heard that somebody actually landed on the moon? Was it you? Not only that, but I'd like to update my UID scheme from a pre-standard version (most of the UIDs are down in the 100s) to the new convention so that I'm more in-line with the rest of the world. Ok, I cannot imagine how you will do this with the access rights of the files? My rough idea: 1) Create a migrate account in Wheel with home as /var/migrate so that I can do a dump/restore on home without messing things up Are you sure? Use /usr to make sure you will have enough space. 2) Start putting together all the pieces - trying to find update / conversion scripts whenever possible. I think, this would only help if you would go the long way 5.x, 6.x, 7x and finally 8. Setup the new machine, install the applications you need, configure them as close as possible to the original configuration and see what happens. 4) Let people move in, try it out, see how things are 5) Fix everything found in #4 6) Try a cut-over and make sure all the network services work in the middle of the night sometime, then switch back Oh, it is a life system in use while you migrate. Are you able to set the new thing up in parallel? It might be easier for you to run both machines and move first the simple things over. 7) Nuke /home and /var/mail and migrate them again to get the latest version 8) Do the real switch 9) spend a couple of weeks fixing all the things that weren't so disastrous that they got picked up in #4. I think, if you do it service by service, you have a better chance to avoid this. Ideas / scripts / project plans / outlines - whatever? Maybe I should write a chapter for The Complete FreeBSD after surviving this... Yes. It is a Le Must. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Hardware migration and upgrade from 6.3 to 8.0 advice
Hello, i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). My current system is alive since 2005, so is full of code, scripts, configurations,lookfeel,ssh keys etc.. that i would like to keep handy in my new system. Also, currently i run gmirror, i am mentioning it, in case it affects something. Since 2005, dealing with programming/support/etc.. i haven't done any upgrade task in FreeBSD, so i dont feel that confident in this regard. I could: a) install a brand new 8.0-RELEASE in the new hardware and then a1) just mount the old disks to the new system or a2) migrate /home user data directly to the new home dirs b) migrate all current data to the new hardware, kernel/system included, and then try to upgrade to 8.0 (by sysinstall or makeworld/makekernel) So, its a trade-off between pain, correctness, effectiveness, and ease of use. What would you guys recommend? Which way to go? Any other options? Thanx in advance! Please include me in your CC, as i am not subscribed to the list. Achilleas Mantzios ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Hardware migration and upgrade from 6.3 to 8.0 advice
Achilleas Mantzios schrieb: Hi! Hello, i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). Well, you know that i386 is Intel, do you? It might work just moving the old kernel to a 64-bit system but I have no experience with it. My current system is alive since 2005, so is full of code, scripts, configurations,lookfeel,ssh keys etc.. that i would like to keep handy in my new system. Also, currently i run gmirror, i am mentioning it, in case it affects something. Since 2005, dealing with programming/support/etc.. i haven't done any upgrade task in FreeBSD, so i dont feel that confident in this regard. I could: a) install a brand new 8.0-RELEASE in the new hardware and then a1) just mount the old disks to the new system or a2) migrate /home user data directly to the new home dirs b) migrate all current data to the new hardware, kernel/system included, and then try to upgrade to 8.0 (by sysinstall or makeworld/makekernel) Item b) is not recommended. There are so many changes AFAIK that it is no clear update. You might do so but then you should update the following way from 6.3 - 7.0 - 7.1 - 7.2 - 8.0 as was recommended on this list earlier (search the archives, please, for further details if you choose this way). For me, a clean install of 8.0 and a move from the old data to the fresh install is better. Use a2) ! Greetings Frank ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Hardware migration and upgrade from 6.3 to 8.0 advice
On Fri, Dec 4, 2009 at 2:57 AM, Achilleas Mantzios mantzios.ach...@yahoo.com wrote: Hello, i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). My current system is alive since 2005, so is full of code, scripts, configurations,lookfeel,ssh keys etc.. that i would like to keep handy in my new system. Also, currently i run gmirror, i am mentioning it, in case it affects something. Since 2005, dealing with programming/support/etc.. i haven't done any upgrade task in FreeBSD, so i dont feel that confident in this regard. I could: a) install a brand new 8.0-RELEASE in the new hardware and then a1) just mount the old disks to the new system or a2) migrate /home user data directly to the new home dirs b) migrate all current data to the new hardware, kernel/system included, and then try to upgrade to 8.0 (by sysinstall or makeworld/makekernel) So, its a trade-off between pain, correctness, effectiveness, and ease of use. What would you guys recommend? Which way to go? Any other options? Thanx in advance! Please include me in your CC, as i am not subscribed to the list. Achilleas Mantzios You may want to consider installing from scratch and migrating over. This would allow you setup zfs and make the move easier. Also may want to explore run ahci(4) as that can seriously increase disk speed although I believe many more improvements live in STABLE, not RELEASE. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Hardware migration and upgrade from 6.3 to 8.0 advice
Frank Wissmann writes: i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). b) migrate all current data to the new hardware, kernel/system included, and then try to upgrade to 8.0 (by sysinstall or makeworld/makekernel) Item b) is not recommended. Confirmed. _Highly_ not recommended. .0 releases usually contain ABI/API changes (among other things) and you don't want anything getting confused. For me, a clean install of 8.0 and a move from the old data to the fresh install is better. To the OP: the machine I'm typing on is also AMD Phenom II x4 (940, if it matters) originally installed with 8.0-RC3/amd64. Once I got past the dangerously dedicated disk issue (and close relatives) everything went smoothly. Of the choices presented, I recommend (a1) with the old disk set to read-only in hardware. New disks are cheap, and this gives you a perfect backup for as long as you want it. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Hardware migration and upgrade from 6.3 to 8.0 advice
Thanx to all. I will keep the old machine for development/maintenance/support, while bulding/testing/migrating the newest versions of software in the new hardware. Up to now, i got the base system/kernel working ok on the new beast, and currently installing additional distributions. All seem fine. Achilleas Mantzios --- On Fri, 12/4/09, Adam Vande More amvandem...@gmail.com wrote: From: Adam Vande More amvandem...@gmail.com Subject: Re: Hardware migration and upgrade from 6.3 to 8.0 advice To: Achilleas Mantzios mantzios.ach...@yahoo.com Cc: freebsd-questions@freebsd.org Date: Friday, December 4, 2009, 1:36 PM On Fri, Dec 4, 2009 at 2:57 AM, Achilleas Mantzios mantzios.ach...@yahoo.com wrote: Hello, i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). My current system is alive since 2005, so is full of code, scripts, configurations,lookfeel,ssh keys etc.. that i would like to keep handy in my new system. Also, currently i run gmirror, i am mentioning it, in case it affects something. Since 2005, dealing with programming/support/etc.. i haven't done any upgrade task in FreeBSD, so i dont feel that confident in this regard. I could: a) install a brand new 8.0-RELEASE in the new hardware and then a1) just mount the old disks to the new system or a2) migrate /home user data directly to the new home dirs b) migrate all current data to the new hardware, kernel/system included, and then try to upgrade to 8.0 (by sysinstall or makeworld/makekernel) So, its a trade-off between pain, correctness, effectiveness, and ease of use. What would you guys recommend? Which way to go? Any other options? Thanx in advance! Please include me in your CC, as i am not subscribed to the list. Achilleas Mantzios You may want to consider installing from scratch and migrating over. This would allow you setup zfs and make the move easier. Also may want to explore run ahci(4) as that can seriously increase disk speed although I believe many more improvements live in STABLE, not RELEASE. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Hardware migration and upgrade from 6.3 to 8.0 advice
On Fri, 04 Dec 2009 14:07:41 +0100 Frank Wissmann frank.wissman...@web.de wrote: Achilleas Mantzios schrieb: Hi! Hello, i am facing this situation, where i need to upgrade from my 6.3 i386 system, used as my main workstation, to a new hardware based on amd64 (phenom II x4). Well, you know that i386 is Intel, do you? No i386 is 32-bit, amd64 is 64-bit, Intel and AMD make both. All amd64 compatible processors are i386 compatible too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: issues with email migration
This morning, I tried adding this to rc.conf and moved my link for /www from local to the nfs . rpc_lockd_enable=YES rpc_statd_enable=YES and I experienced the same issues I had before. It would seem that postfix and other assorted mail programs have no issue with accessing /mail on an nfs share but everything residing in /www don't seem to like it at all. I have no choice but to leave this as it is and set up a similar arrangement on my new server. Thank you to everyone who responded. -Original Message- From: Tim Judd [mailto:taj...@gmail.com] Sent: Saturday, October 31, 2009 10:51 AM To: da...@farmington.k12.mo.us Cc: freebsd-questions@freebsd.org Subject: Re: issues with email migration On 10/31/09, da...@farmington.k12.mo.us da...@farmington.k12.mo.us wrote: only one issue with that. The server in question is an emc clereon(sorry not at work to look at the specifics) and at this point the only access I have to it is a web interface and am unable to access a command line. Also a stupid question my plan is to set up another server to access the nfs share to provide better email service. would this impact it in any way? snip replies Not if file locking and the daemons take care of everything like they should. Remember, file locking is mandatory for some things, especially mbox files, password files, or anything else that requires exclusive access to a file. If two systems try to access the same locked file, the 2nd will be told it won't be able to get an exclusive lock, because the 1st already has it locked. You're on the right track. Keep it going. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: issues with email migration
On 11/2/09, David Patton da...@farmington.k12.mo.us wrote: This morning, I tried adding this to rc.conf and moved my link for /www from local to the nfs . rpc_lockd_enable=YES rpc_statd_enable=YES Adding them alone just tells the system at startup to start these. and I experienced the same issues I had before. It would seem that postfix and other assorted mail programs have no issue with accessing /mail on an nfs share but everything residing in /www don't seem to like it at all. Did you start statd and lockd by hand before trying the /www again? I have no choice but to leave this as it is and set up a similar arrangement on my new server. Thank you to everyone who responded. -Original Message- From: Tim Judd [mailto:taj...@gmail.com] Sent: Saturday, October 31, 2009 10:51 AM To: da...@farmington.k12.mo.us Cc: freebsd-questions@freebsd.org Subject: Re: issues with email migration On 10/31/09, da...@farmington.k12.mo.us da...@farmington.k12.mo.us wrote: only one issue with that. The server in question is an emc clereon(sorry not at work to look at the specifics) and at this point the only access I have to it is a web interface and am unable to access a command line. Also a stupid question my plan is to set up another server to access the nfs share to provide better email service. would this impact it in any way? snip replies Not if file locking and the daemons take care of everything like they should. Remember, file locking is mandatory for some things, especially mbox files, password files, or anything else that requires exclusive access to a file. If two systems try to access the same locked file, the 2nd will be told it won't be able to get an exclusive lock, because the 1st already has it locked. You're on the right track. Keep it going. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: issues with email migration
Yes sir, I added them to the rc.conf, changed the links to point where I wanted them and rebooted, same issues. I cant waste anymore time with what I wanted to do. I will leave /mail on the nfs share and just build a new server. I have 2 days and hopefully I will keep my job. Wish me luck... -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Tim Judd Sent: Monday, November 02, 2009 10:10 AM To: David Patton Cc: freebsd-questions@freebsd.org Subject: Re: issues with email migration On 11/2/09, David Patton da...@farmington.k12.mo.us wrote: This morning, I tried adding this to rc.conf and moved my link for /www from local to the nfs . rpc_lockd_enable=YES rpc_statd_enable=YES Adding them alone just tells the system at startup to start these. and I experienced the same issues I had before. It would seem that postfix and other assorted mail programs have no issue with accessing /mail on an nfs share but everything residing in /www don't seem to like it at all. Did you start statd and lockd by hand before trying the /www again? I have no choice but to leave this as it is and set up a similar arrangement on my new server. Thank you to everyone who responded. -Original Message- From: Tim Judd [mailto:taj...@gmail.com] Sent: Saturday, October 31, 2009 10:51 AM To: da...@farmington.k12.mo.us Cc: freebsd-questions@freebsd.org Subject: Re: issues with email migration On 10/31/09, da...@farmington.k12.mo.us da...@farmington.k12.mo.us wrote: only one issue with that. The server in question is an emc clereon(sorry not at work to look at the specifics) and at this point the only access I have to it is a web interface and am unable to access a command line. Also a stupid question my plan is to set up another server to access the nfs share to provide better email service. would this impact it in any way? snip replies Not if file locking and the daemons take care of everything like they should. Remember, file locking is mandatory for some things, especially mbox files, password files, or anything else that requires exclusive access to a file. If two systems try to access the same locked file, the 2nd will be told it won't be able to get an exclusive lock, because the 1st already has it locked. You're on the right track. Keep it going. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: issues with email migration
only one issue with that. The server in question is an emc clereon(sorry not at work to look at the specifics) and at this point the only access I have to it is a web interface and am unable to access a command line. Also a stupid question my plan is to set up another server to access the nfs share to provide better email service. would this impact it in any way? thank you again On 10/30/09, usleepl...@gmail.com usleepl...@gmail.com wrote: Hi David, On Fri, Oct 30, 2009 at 1:59 PM, David Patton da...@farmington.k12.mo.uswrote: This morning I moved the contents from the server over to an NFS share. This is a freebsd 6.2 server running postfix, courier-imap and squirrelmail. I used rsync to move the data for /www and /mail over to the nfs share. After I made the changed to fstab and rebooted, every thing came up and email seemed to be faster but in fact it wasn't. Once I realized that there was an issue, I changed the link back for the /www directory to the original location and left the link for /mail pointing to the nfs share. I found from a search to try newaliaies and the restart postfix but that didn't work. Maillog: Oct 30 06:11:38 bonnie postfix/smtpd[1337]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:11:39 bonnie postfix/master[889]: warning: process /usr/local/libexec/postfix/smtpd pid 1337 exit status 1 Oct 30 06:11:39 bonnie postfix/master[889]: warning: /usr/local/libexec/postfix/smtpd: bad command startup - throttling Message: Oct 30 06:00:27 bonnie postfix/smtpd[1177]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:01:28 bonnie postfix/smtpd[1184]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:02:29 bonnie postfix/smtpd[1192]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:03:30 bonnie postfix/smtpd[1218]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:04:31 bonnie postfix/smtpd[1235]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:05:32 bonnie postfix/smtpd[1256]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:06:33 bonnie postfix/smtpd[1270]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:07:34 bonnie postfix/smtpd[1296]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:08:35 bonnie postfix/smtpd[1307]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported although i am certainly not an expert regarding email issues nor NFS, but could it be that the NFS server needs to support lockd and statd ? i have this in my /etc/rc.conf: rpc_lockd_enable=YES rpc_statd_enable=YES On both the server and client. File locking is not supported without these two daemons running. I run diskless clients and I need to support file locking, for when you edit the passwd file with vipw and the like. Please enable the above on both the server and client, start them, then try again. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: issues with email migration
On 10/31/09, da...@farmington.k12.mo.us da...@farmington.k12.mo.us wrote: only one issue with that. The server in question is an emc clereon(sorry not at work to look at the specifics) and at this point the only access I have to it is a web interface and am unable to access a command line. Also a stupid question my plan is to set up another server to access the nfs share to provide better email service. would this impact it in any way? snip replies Not if file locking and the daemons take care of everything like they should. Remember, file locking is mandatory for some things, especially mbox files, password files, or anything else that requires exclusive access to a file. If two systems try to access the same locked file, the 2nd will be told it won't be able to get an exclusive lock, because the 1st already has it locked. You're on the right track. Keep it going. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
issues with email migration
This morning I moved the contents from the server over to an NFS share. This is a freebsd 6.2 server running postfix, courier-imap and squirrelmail. I used rsync to move the data for /www and /mail over to the nfs share. After I made the changed to fstab and rebooted, every thing came up and email seemed to be faster but in fact it wasn't. Once I realized that there was an issue, I changed the link back for the /www directory to the original location and left the link for /mail pointing to the nfs share. I found from a search to try newaliaies and the restart postfix but that didn't work. Maillog: Oct 30 06:11:38 bonnie postfix/smtpd[1337]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:11:39 bonnie postfix/master[889]: warning: process /usr/local/libexec/postfix/smtpd pid 1337 exit status 1 Oct 30 06:11:39 bonnie postfix/master[889]: warning: /usr/local/libexec/postfix/smtpd: bad command startup - throttling Message: Oct 30 06:00:27 bonnie postfix/smtpd[1177]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:01:28 bonnie postfix/smtpd[1184]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:02:29 bonnie postfix/smtpd[1192]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:03:30 bonnie postfix/smtpd[1218]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:04:31 bonnie postfix/smtpd[1235]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:05:32 bonnie postfix/smtpd[1256]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:06:33 bonnie postfix/smtpd[1270]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:07:34 bonnie postfix/smtpd[1296]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:08:35 bonnie postfix/smtpd[1307]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Any thoughts on the subject? Thanks in advance. David Patton Technology Department Farmington R7 School District ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: issues with email migration
Hi David, On Fri, Oct 30, 2009 at 1:59 PM, David Patton da...@farmington.k12.mo.uswrote: This morning I moved the contents from the server over to an NFS share. This is a freebsd 6.2 server running postfix, courier-imap and squirrelmail. I used rsync to move the data for /www and /mail over to the nfs share. After I made the changed to fstab and rebooted, every thing came up and email seemed to be faster but in fact it wasn't. Once I realized that there was an issue, I changed the link back for the /www directory to the original location and left the link for /mail pointing to the nfs share. I found from a search to try newaliaies and the restart postfix but that didn't work. Maillog: Oct 30 06:11:38 bonnie postfix/smtpd[1337]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:11:39 bonnie postfix/master[889]: warning: process /usr/local/libexec/postfix/smtpd pid 1337 exit status 1 Oct 30 06:11:39 bonnie postfix/master[889]: warning: /usr/local/libexec/postfix/smtpd: bad command startup - throttling Message: Oct 30 06:00:27 bonnie postfix/smtpd[1177]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:01:28 bonnie postfix/smtpd[1184]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:02:29 bonnie postfix/smtpd[1192]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:03:30 bonnie postfix/smtpd[1218]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:04:31 bonnie postfix/smtpd[1235]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:05:32 bonnie postfix/smtpd[1256]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:06:33 bonnie postfix/smtpd[1270]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:07:34 bonnie postfix/smtpd[1296]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:08:35 bonnie postfix/smtpd[1307]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported although i am certainly not an expert regarding email issues nor NFS, but could it be that the NFS server needs to support lockd and statd ? i have this in my /etc/rc.conf: rpc_lockd_enable=YES rpc_statd_enable=YES kind regards, usleep ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: issues with email migration
On 10/30/09, usleepl...@gmail.com usleepl...@gmail.com wrote: Hi David, On Fri, Oct 30, 2009 at 1:59 PM, David Patton da...@farmington.k12.mo.uswrote: This morning I moved the contents from the server over to an NFS share. This is a freebsd 6.2 server running postfix, courier-imap and squirrelmail. I used rsync to move the data for /www and /mail over to the nfs share. After I made the changed to fstab and rebooted, every thing came up and email seemed to be faster but in fact it wasn't. Once I realized that there was an issue, I changed the link back for the /www directory to the original location and left the link for /mail pointing to the nfs share. I found from a search to try newaliaies and the restart postfix but that didn't work. Maillog: Oct 30 06:11:38 bonnie postfix/smtpd[1337]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:11:39 bonnie postfix/master[889]: warning: process /usr/local/libexec/postfix/smtpd pid 1337 exit status 1 Oct 30 06:11:39 bonnie postfix/master[889]: warning: /usr/local/libexec/postfix/smtpd: bad command startup - throttling Message: Oct 30 06:00:27 bonnie postfix/smtpd[1177]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:01:28 bonnie postfix/smtpd[1184]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:02:29 bonnie postfix/smtpd[1192]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:03:30 bonnie postfix/smtpd[1218]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:04:31 bonnie postfix/smtpd[1235]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:05:32 bonnie postfix/smtpd[1256]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:06:33 bonnie postfix/smtpd[1270]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:07:34 bonnie postfix/smtpd[1296]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported Oct 30 06:08:35 bonnie postfix/smtpd[1307]: fatal: shared-lock database /www/mailman/data/aliases.db for open: Operation not supported although i am certainly not an expert regarding email issues nor NFS, but could it be that the NFS server needs to support lockd and statd ? i have this in my /etc/rc.conf: rpc_lockd_enable=YES rpc_statd_enable=YES On both the server and client. File locking is not supported without these two daemons running. I run diskless clients and I need to support file locking, for when you edit the passwd file with vipw and the like. Please enable the above on both the server and client, start them, then try again. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ezjail jail migration
Has anyone tried to migrate ezjail jails between 7.2 and 6.4? I've read it works fine 6.4 - 7.2, but what about 7.2 - 6.4. Is there any chance I could get away with this by not being forced to reinstall all the running stuff - proftpd, apache? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to do a live migration of a freebsd box to another box with rsync
On Sun, Jul 05, 2009 at 06:18:03PM +0200, insrc typed: Hi, I'm used to migrate GNU/Linux system from one box to another by booting the second box with a liveCD (like systemrescueCD for example) and by copying the / filesystem (using the ssh transport) with rsync. I would like to do the same for BSD system but i have two issues: - as the UFS write support is still experimental in the Linux kernel, it seems that i've to use a BSD liveCD but i can't find one :-/ I heard about frenzy ( http://frenzy.org.ua/en/ ) but the homepage says that the project is no longer maintained ! - i'm wondering how to restore the bootloader after copying the files on the second box. On linux, i can use the grub-install script to do the job but i'm a bit lost on FreeBSD :-) Assuming you install on the first slice of the first disk (ad0s1), to install the bootloader and bootstrap code: fdisk -B ad0 bsdlabel -B ad0s1 Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to do a live migration of a freebsd box to another box with rsync
Hi, I'm used to migrate GNU/Linux system from one box to another by booting the second box with a liveCD (like systemrescueCD for example) and by copying the / filesystem (using the ssh transport) with rsync. I would like to do the same for BSD system but i have two issues: - as the UFS write support is still experimental in the Linux kernel, it seems that i've to use a BSD liveCD but i can't find one :-/ I heard about frenzy ( http://frenzy.org.ua/en/ ) but the homepage says that the project is no longer maintained ! - i'm wondering how to restore the bootloader after copying the files on the second box. On linux, i can use the grub-install script to do the job but i'm a bit lost on FreeBSD :-) Hello. The Frenzy distro is still quite usable albeit it was abandoned. ;) Also you can find official FreeBSD liveCD iso here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i.386/ISO-IMAGES/7.2/7.2-RELEASE-i386-livefs.iso (change arch type according to you platform). -- Best regards, Jeff | Nobody wants to say how this works. | | Maybe nobody knows ... | | Xorg.conf(5)| ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to do a live migration of a freebsd box to another box with rsync
Hi, Thanks guys, everything worked perfectly ! - For the liveCD, i booted the second box with FreeNAS ( http://www.freenas.org/index.php?lang=fr ) , which include rsync and ssh :-) - Created the partition layout following the official doc http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-adding.html. @Ruben: Thanks for your help btw for restoring the bootloader :-) - Then just rsynced the / filesystem excluding the /dev directory. - Ajusted /etc/fstab - Voilà ! Seems easier than a migration of GNU/Linux after all :) Thanks again for your help ! Cheers, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
how to do a live migration of a freebsd box to another box with rsync
Hi, I'm used to migrate GNU/Linux system from one box to another by booting the second box with a liveCD (like systemrescueCD for example) and by copying the / filesystem (using the ssh transport) with rsync. I would like to do the same for BSD system but i have two issues: - as the UFS write support is still experimental in the Linux kernel, it seems that i've to use a BSD liveCD but i can't find one :-/ I heard about frenzy ( http://frenzy.org.ua/en/ ) but the homepage says that the project is no longer maintained ! - i'm wondering how to restore the bootloader after copying the files on the second box. On linux, i can use the grub-install script to do the job but i'm a bit lost on FreeBSD :-) Thanks for your help ! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to do a live migration of a freebsd box to another box with rsync
insrc informatique@gmail.com wrote: it seems that i've to use a BSD liveCD but i can't find one :-/ www.freesbie.org The site is not responding for me ATM, but the text is cached here: http://74.125.155.132/search?q=cache:WjK0Anp5tb4J:www.freesbie.org/+freesbie+freebsdhl=engl=usstrip=1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to do a live migration of a freebsd box to another box with rsync
Hi, Am Sonntag, 05. Jul 2009, 18:18:03 +0200 schrieb insrc: - as the UFS write support is still experimental in the Linux kernel, it seems that i've to use a BSD liveCD but i can't find one :-/ I heard about frenzy ( http://frenzy.org.ua/en/ ) but the homepage says that the project is no longer maintained ! There is a livefs with the original ISO images: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2/ I further found DesktopBSD but I didn't try that. I strongly recommend that you build yourself an USB stick. Here's what you need to do: http://typo.submonkey.net/articles/2006/4/13/installing-freebsd-on-usb-stick-episode-2 I went forth, chrooted into the stick and installed Vim, some diagnose/repair tools and an XFCE. I even managed to install Grub and let the user switch the boot process back to the hard disk. Further, I made a second partition named transfer formatted with FAT so that I can write some data from a Windows to it. I look enviously at the Grml project and I find it a great pity that there is no BSD equivalent. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Migration to 7.1 ?
Hello I'm planning to migrate our mailhub (IBM X3650) to FreeBSD 7.1 from Debian etch ;-) , of course I'll restart from scratch. I have two questions before doing so. Does 7.1 has reached a stability that it could be used for a high load production server ? Does the LAGG driver works well with broadcomm giga ethernet chips ? ( I plan to use LACP to a Cisco switch ) Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration to 7.1 ?
Does 7.1 has reached a stability that it could be used for a high load production server ? at least for me - it's stable under high loads doing lots of different thing. i mean /amd64 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration to 7.1 ?
Frank Bonnet wrote: Hello I'm planning to migrate our mailhub (IBM X3650) to FreeBSD 7.1 from Debian etch ;-) , of course I'll restart from scratch. I have two questions before doing so. Does 7.1 has reached a stability that it could be used for a high load production server ? Generally, yes. Does the LAGG driver works well with broadcomm giga ethernet chips ? ( I plan to use LACP to a Cisco switch ) Try asking at freebsd-net@ signature.asc Description: OpenPGP digital signature
Re: Migration to 7.1 ?
Does the LAGG driver works well with broadcomm giga ethernet chips ? ( I plan to use LACP to a Cisco switch ) Try asking at freebsd-net@ Hi, I've been running with the lagg-driver for quite some time now on several blade-systems using broadcom chips in a failover configuration - no problems whatsoever - failover/fallback all ok. LACP shouldn't be a problem either - on the Cisco side define a port channel using LACP plus optional a balancing strategy (like mac-based etc.) HTH -ewald ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Migration to 7.1 ?
Ewald Jenisch wrote: Does the LAGG driver works well with broadcomm giga ethernet chips ? ( I plan to use LACP to a Cisco switch ) Try asking at freebsd-net@ Hi, I've been running with the lagg-driver for quite some time now on several blade-systems using broadcom chips in a failover configuration - no problems whatsoever - failover/fallback all ok. LACP shouldn't be a problem either - on the Cisco side define a port channel using LACP plus optional a balancing strategy (like mac-based etc.) HTH -ewald Hello Thanks for your feedback Frank ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RAID migration
Dear freebsd-questions, I have a HighPoint 1820 RAID controller that is using 1 channel for an OS drive and 3 channels for a RAID-5 array. I'm interested in migrating to a new (possibly non-HighPoint) card, and am wondering if I will be able to plug the OS drive into one channel on the new card and have it just work. Is it a safe bet that it will? I'm curious to know if the array could be migrated just as easily, or if I should listen to my instinct and count on bumping into incompatibilities due to proprietary implementations. Here are the relevant dmesg lines of my system as it stands: hptrr: HPT RocketRAID controller driver v1.1 (Jun 7 2008 14:01:57) hptmv0: RocketRAID 182x SATA Controller mem 0xf200-0xf207 irq 24 at device 1.0 on pci2 hptmv0: [GIANT-LOCKED] hptmv0: [ITHREAD] hptrr: no controller detected. da0 at hptmv0 bus 0 target 0 lun 0 da0: Maxtor 6 Y080M0 YAR5 Fixed Direct Access SCSI-0 device da1 at hptmv0 bus 0 target 1 lun 0 da1: RR182x RAID 5 Array 3.00 Fixed Direct Access SCSI-0 device -- Anthony Chavez http://hexadecagram.org/ mailto:[EMAIL PROTECTED]xmpp:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID migration
On Sun, Oct 12, 2008 at 07:10:31PM -0600, Anthony Chavez wrote: Dear freebsd-questions, I have a HighPoint 1820 RAID controller that is using 1 channel for an OS drive and 3 channels for a RAID-5 array. I'm interested in migrating to a new (possibly non-HighPoint) card, and am wondering if I will be able to plug the OS drive into one channel on the new card and have it just work. Is it a safe bet that it will? It probably will work, assuming that the OS disk is not configured as a RAID or array member in the RAID cards' BIOS. Meaning, if you're using the disk on the controller purely in a JBOD fashion, yes, it should work. I'm curious to know if the array could be migrated just as easily, or if I should listen to my instinct and count on bumping into incompatibilities due to proprietary implementations. I can absolutely guarantee you that you will lose access to all of your data once you plug those 3 disks into another controller. You need to back up all of your data from the RAID-5 array using something like rsync, cpdup, or dump, move the disks over to the non-RAID controller, format them (in whatever fashion you want), and then restore the backup. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID migration
Jeremy Chadwick wrote: On Sun, Oct 12, 2008 at 07:10:31PM -0600, Anthony Chavez wrote: Dear freebsd-questions, I have a HighPoint 1820 RAID controller that is using 1 channel for an OS drive and 3 channels for a RAID-5 array. I'm interested in migrating to a new (possibly non-HighPoint) card, and am wondering if I will be able to plug the OS drive into one channel on the new card and have it just work. Is it a safe bet that it will? It probably will work, assuming that the OS disk is not configured as a RAID or array member in the RAID cards' BIOS. Meaning, if you're using the disk on the controller purely in a JBOD fashion, yes, it should work. In the WebGUI's logical device information section, that particular drive is listed as a hard disk whereas the other 3 are clearly spelled out as a RAID 5 array. When I shut the machine down, I will check the BIOS itself to see if it specifically states JBOD. Thanks for the pointer. Regardless, I will be backing it up before I attempt to plug it into a new RAID controller. I'm curious to know if the array could be migrated just as easily, or if I should listen to my instinct and count on bumping into incompatibilities due to proprietary implementations. I can absolutely guarantee you that you will lose access to all of your data once you plug those 3 disks into another controller. You need to back up all of your data from the RAID-5 array using something like rsync, cpdup, or dump, move the disks over to the non-RAID controller, format them (in whatever fashion you want), and then restore the backup. Exactly what I planned to do, but figured I'd ask anyhow. ;-) Thank you for responding. -- Anthony Chavez http://hexadecagram.org/ mailto:[EMAIL PROTECTED]xmpp:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID migration
On Sun, Oct 12, 2008 at 10:27:47PM -0600, Anthony Chavez wrote: Jeremy Chadwick wrote: On Sun, Oct 12, 2008 at 07:10:31PM -0600, Anthony Chavez wrote: Dear freebsd-questions, I have a HighPoint 1820 RAID controller that is using 1 channel for an OS drive and 3 channels for a RAID-5 array. I'm interested in migrating to a new (possibly non-HighPoint) card, and am wondering if I will be able to plug the OS drive into one channel on the new card and have it just work. Is it a safe bet that it will? It probably will work, assuming that the OS disk is not configured as a RAID or array member in the RAID cards' BIOS. Meaning, if you're using the disk on the controller purely in a JBOD fashion, yes, it should work. In the WebGUI's logical device information section, that particular drive is listed as a hard disk whereas the other 3 are clearly spelled out as a RAID 5 array. When I shut the machine down, I will check the BIOS itself to see if it specifically states JBOD. Thanks for the pointer. It probably won't. JBOD is just a term used to describe a hard disk hooked to a RAID controller but not part of a RAID array. I'd start by pulling the OS disk out and hooking it to a non-Highpoint controller and ensure it boots. Chances are it will. Some advice, assuming you haven't done this before: 1) Make note of what your filesystem layout is before migrating. df output should be sufficient. 2) When you boot it, FreeBSD will probably complain unable to determine root filesystem. I'm guessing these are ATA/SATA disks. The kernel messages shown should list off what ATA disks are attached, and you'll have to make some educated guesses as to what it is, e.g. ufs:ad4s1a rather than the old ufs:da0s1a. You'll have to mount all the filesystems by hand (mount /dev/ad4s1d /var, etc. -- this is what #1 was for :-) ) so you can get access to vi, so you can vi /etc/fstab and fix the problem. You can also use ed(1) to do the fstab editing without having to mount everything, if you're familiar with it. Hope this helps. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD - FreeBSD migration
The results of my investigation so far are below: Filesystem stuff: - it appears that FreeBSD and OpenBSD use the same partition table format. Is this true? If so, I can potentially avoid rebuilding an entire disk if I am right that ... - FreeBSD can mount and read OpenBSD's version of the 4.2 BSD filesystem implementation Although I strongly suspect that the filesystem itself is probably the same, it is not possible to read an OpenBSD mounted partition, as far as I can tell. After booting using FreeBSD, fdisk correctly reports the information regarding the slice set up by OpenBSD (default 4, not 1, the FreeBSD default), however bsdlabel under FreeBSD cannot interpret any of the data found at the location reported in the table read by fdisk. I do find this somewhat surprising, as it is the same structures that are being recorded. Perhaps there is a magic number issue here that causes bsdlabel to believe that it can't interpret the data as the message returned is that there is no label present in the indicated slice. This makes the filesystem question moot, as without access to the BSD partition results there is no clue as to where to begin access of the filesystem. - even if the above isn't true, it appears that the format used by dump/restore is consistent. I have tried dumping/restoring some small filesystems to test this, but if this is an unsupported way to go, I would like to know now. This seems to work. I was successfully able to dump filesystems under OpenBSD and then restore them under FreeBSD, with general success (albeit a complaint that the dump header is out of date). Cheers, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD - FreeBSD migration
Andrew Wright wrote: Hi All; I want to migrate a system from OpenBSD 4.2 (ie; the current version) to FreeBSD (7.0). I have poked around on the archives a little to determine how best to do this, and I want to make sure that my understanding (summarized below) is indeed correct. If I am asking these questions on the wrong list (potentially likely for the AMD specific questions) then please let me know: Filesystem stuff: - it appears that FreeBSD and OpenBSD use the same partition table format. Is this true? If so, I can potentially avoid rebuilding an entire disk if I am right that ... No, I don't think that's true. In any case, you can verify it by booting a live-CD of FreeBSD and trying it. If both of these are true, I can simply install FreeBSD over top of the OpenBSD /, /var and /usr partitions, and then be able to mount the old /home. Is this something people do? If you delete everything from all directories except /home, it might work. Otherwise, the risk of getting mixed binaries, libraries and scripts from both systems is too great. Processor stuff: - The machine of interest has an AMD64 processor. I have seen several references to running Linux emulation on an AMD processor, but I would like to confirm that this is true while running the 64-bit version of the OS. In other words: - with a 64-bit installation (amd64) of FreeBSD 7.0, emulation of 32-bit Linux binaries (notably Matlab, but possibly other software as well) is possible, and indeed a reasonably well-known way of proceeding. I think 32-bit Linux binaries should be supported on 64-bit FreeBSD alongside 32-bit FreeBSD binaries. signature.asc Description: OpenPGP digital signature
Re: OpenBSD - FreeBSD migration
Ivan Voras wrote: Andrew Wright wrote: If both of these are true, I can simply install FreeBSD over top of the OpenBSD /, /var and /usr partitions, and then be able to mount the old /home. Is this something people do? If you delete everything from all directories except /home, it might work. Otherwise, the risk of getting mixed binaries, libraries and scripts from both systems is too great. I probably should have been more clear in my initial post -- I am certainly intending on relabelling + reformatting partitions for /, /usr, /var, /tmp and so on -- to try to run these with a potential filesystem incompatbility (not to mention the potential of mixed binaries) is just asking for trouble. What I am hoping to do is run dump | restore, as the various userdata partitions are all on separate drives (in a partitions), and I have enough space to dump the first one and compress it onto another user-space drive, and similar jiggery-pokery (Doing this will save _many_ media swaps, and thus much time). Essentially, I am asking whether _readonly_ access works, for which I will need FreeBSD to read the disklabel and the filesystem. Thought I'd clear that up in case a perusal through the archives steered anyone wrong later one. Thanks to everyone who pointed out the live CD, I think that will let me answer most, if not all, of my questions. Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenBSD - FreeBSD migration
Hi All; I want to migrate a system from OpenBSD 4.2 (ie; the current version) to FreeBSD (7.0). I have poked around on the archives a little to determine how best to do this, and I want to make sure that my understanding (summarized below) is indeed correct. If I am asking these questions on the wrong list (potentially likely for the AMD specific questions) then please let me know: Filesystem stuff: - it appears that FreeBSD and OpenBSD use the same partition table format. Is this true? If so, I can potentially avoid rebuilding an entire disk if I am right that ... - FreeBSD can mount and read OpenBSD's version of the 4.2 BSD filesystem implementation If both of these are true, I can simply install FreeBSD over top of the OpenBSD /, /var and /usr partitions, and then be able to mount the old /home. Is this something people do? - even if the above isn't true, it appears that the format used by dump/restore is consistent. I have tried dumping/restoring some small filesystems to test this, but if this is an unsupported way to go, I would like to know now. Also, before someone (quite rightly) says back up your data, I will note that the reason that I would like to be able to read from /home is to avoid a lengthy restore -- all this data is backed up, but if there is no reason to re-label the drive and reformat the various user data partitions (on various drives) and then spend a day running restore, then I would like avoid such a waste of time. If this is even slightly likely to cause problems though, please let me know and I will start swapping media. - if I have somehow misled myself that restore(8) is consistent, please let me know -- re-installing the old OS just to back up to some other format would be a giant waste of time. Processor stuff: - The machine of interest has an AMD64 processor. I have seen several references to running Linux emulation on an AMD processor, but I would like to confirm that this is true while running the 64-bit version of the OS. In other words: - with a 64-bit installation (amd64) of FreeBSD 7.0, emulation of 32-bit Linux binaries (notably Matlab, but possibly other software as well) is possible, and indeed a reasonably well-known way of proceeding. If I'm crazy, and/or misreading the docs, please let me know. Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD - FreeBSD migration
On Sun 2008-04-20 15:59:14 UTC-0400, Andrew Wright ([EMAIL PROTECTED]) wrote: - it appears that FreeBSD and OpenBSD use the same partition table format. Is this true? If so, I can potentially avoid rebuilding an entire disk if I am right that ... - FreeBSD can mount and read OpenBSD's version of the 4.2 BSD filesystem implementation My understanding is that the second ISO image of FreeBSD (eg. 7.0-RELEASE-i386-disc2.iso) is a Live CD. That should enable you to boot FreeBSD from CD and attempt to mount the file system (read-only or read-write) that your OpenBSD installation lives on. If both of these are true, I can simply install FreeBSD over top of the OpenBSD /, /var and /usr partitions, and then be able to mount the old /home. Is this something people do? I think prior to the FreeBSD install you would want to erase all files in /, /var and /usr to remove any cruft that would be otherwise left over from the previous OpenBSD installation. Maybe I'm paranoid, but I would be wary of file system reliability between two OSes, especially on a production system. On the other hand maybe there is someone reading this who is successfully dual booting FreeBSD and OpenBSD and sharing /home that may want to comment further. Failing that, you could do some testing on a spare PC or in a VM. I can't comment on the dump/restore or Linux compatibility. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Password file migration help
Sean Murphy 写道: I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] awk -F: '{if($4 3000) if($4 5000) print $0}' /etc/master.passwd You should do it as root. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Password file migration help
On Wednesday 30 January 2008 20:26:20 Vince wrote: Sean Murphy wrote: I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? hmm very roughly just a for uid in $(jot 2001 3000); do grep $uid /etc/master.passwd accountstokeep.txt ; done That's a bit loose, and forgot a dash. The following should really only get the uid's (not the gids, parts of a password, comments and what not): for uid in $(jot - 2001 3000); do \ grep -E ^[^:]+:[^:]+:$uid: /etc/master.passwd; done This doesn't migrate home dirs, but using the above and piping to: cut -f 9 -d ':' should give you a list of home dirs to work with. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Password file migration help
I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Password file migration help
Sean Murphy wrote: I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Open vi/vim/etc on both machines via `vipw`, and copy 'n' paste. Repeat for the group file in necessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Password file migration help
Sean Murphy wrote: I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? hmm very roughly just a for uid in $(jot 2001 3000); do grep $uid /etc/master.passwd accountstokeep.txt ; done should extract the accounts from the old server (no error checking though so if any other account has a gid in the range 3000 to 5000 it will also be caught. Then in theory cat accountstokeep.txt /etc/master.passwd followed by pwd_mkdb -p /etc/master.passwd should be enough. Again care should be taken that there are no conflicting accounts already in the /etc/master.passwd file. (a quick for uid in $(jot 2001 3000); do grep $uid /etc/master.passwd ; done on the new machine before adding to it should give you a quick check.) dont forget to ensure shells and home directories are available as needed Vince Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Password file migration help
On Wednesday 30 January 2008 21:03, Sean Murphy wrote: I have a FreeBSD 5.4 system and would like to migrate users in the password file with UIDs 3000 through 5000 to a FreeBSD 6.3 system on a running on a separate box. Is there a way to export just those users? I'd probably sort /etc/master.passwd and pipe through awk: sort -t ':' -k3,3n /etc/master.passwd | \ awk -F ':' '$3 ~ /^3[0-9][0-9][0-9]/, $3 ~ /^5/ { print }' This will sort /etc/master.passwd numerically on the third field, uid, and then give you all the lines starting with the first one where the uid is a 3 followed by at least three digits, up to and including the first one after that where the first digit of the uid is a 5. If you capture the output you should be able to merge it on the new host. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
machine migration from 5.3 to 6.3
Okay, I had a freshly installed 6.3 on a machine (thanks Derek Ragona), and my intention is to use this new installation as a direct replacement of an older 5.3 box. This means using the same host name, IP address, and services. I want to make sure I've crossed all the t's. I installed ilohamail and since I'm using mysql for the database, I need to bring over the tables. So I use mysqladmin to copy all databases and their tables from the old box and restore them on my new box. Copy over my users' home directories, and copy the /etc/master.passwd and /etc/passwd files. I need to bring over the old httpd.conf file so my virtual hosts are preserved. Also bring over the related directories with content. Run #hostname new.name to change the hostname, and edit the /etc/rc.conf file to make the change permanent. Edit the /etc/hosts file also, or copy over the old one. To change the address, vi the /etc/rc.conf file to edit the if_config lines (disconnect the old box from the network, first) and run #/etc/netstart Now I'm really unsure of this step: since this box is an important dns host, couldn't I copy the entre /var/named structure over? Or is is best to create fresh ones? It was well over two years ago when I set bind/rndc up, and I remember not enjoying that. I was hoping to use the same zone records. I'm the only one who ssh's in, so I don't care about those keys, but my main concern is to have the mail/dns flowing the way it was before. The mail is handled by a third party's (Sophos) own postfix implementation, and they have their own postgres database. Is there anything I've missed, or am way off on? Thanks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: machine migration from 5.3 to 6.3
At 03:51 PM 1/28/2008, Josh Tremor wrote: Okay, I had a freshly installed 6.3 on a machine (thanks Derek Ragona), and my intention is to use this new installation as a direct replacement of an older 5.3 box. This means using the same host name, IP address, and services. I want to make sure I've crossed all the t's. I installed ilohamail and since I'm using mysql for the database, I need to bring over the tables. So I use mysqladmin to copy all databases and their tables from the old box and restore them on my new box. Copy over my users' home directories, and copy the /etc/master.passwd and /etc/passwd files. I need to bring over the old httpd.conf file so my virtual hosts are preserved. Also bring over the related directories with content. Run #hostname new.name to change the hostname, and edit the /etc/rc.conf file to make the change permanent. Edit the /etc/hosts file also, or copy over the old one. To change the address, vi the /etc/rc.conf file to edit the if_config lines (disconnect the old box from the network, first) and run #/etc/netstart Now I'm really unsure of this step: since this box is an important dns host, couldn't I copy the entre /var/named structure over? Or is is best to create fresh ones? It was well over two years ago when I set bind/rndc up, and I remember not enjoying that. I was hoping to use the same zone records. I'm the only one who ssh's in, so I don't care about those keys, but my main concern is to have the mail/dns flowing the way it was before. The mail is handled by a third party's (Sophos) own postfix implementation, and they have their own postgres database. Is there anything I've missed, or am way off on? Thanks. Usually I tar up and move and untar /etc /usr/local /home and possibly /var depending on what you have there. You don't need to disconnect the old box, you can just swap the ip's if you want between the boxes so both are still on your netowrk. Swapping ip's requires a different /etc/rc.conf file and a hosts file that reflects the current ip and hostname. This is easily done creating a second /etc/rc.conf file say /etc/rc.conf.new edit this file. Do the same with /etc/hosts to /etc/hosts.new To swap the ip's create a shell script such as: = #!/bin/sh /bin/mv /etc/rc.conf /etc/rc.conf.old /bin/mv /etc/rc.conf.new /etc/rc.conf /bin/mv /etc/hosts /etc/hosts.old /bin/mv /etc/hosts.new /etc/hosts /sbin/reboot = Assuming you run this on both machines with the correctly edited files, each will reboot to the other's old IP. That way if you need to copy things, you still can do so easily. If you move filesystems between servers run mergemaster once you are done to see if you have any out of date or missing files as you are moving from 5.x to 6.x. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.2.1 to 6.2 Migration.
Kevin Kinsey [EMAIL PROTECTED] writes: Lowell Gilbert wrote: Chris Haulmark [EMAIL PROTECTED] writes: Grant Peel wrote: I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. It's a good safety precaution; if your updated kernel won't boot, you will need to reinstall most of the system. That is over the board. Only times that I have made the mistakes in the past are: 1. Misconfiguring the kernel options such as disabling the meeded network driver built in the kernel. 2. Anything related to having kernel panics to occur. 3. Enabling firewall and getting locked out via network. That sounds a tad alarmist; if the new kernel won't boot, you'll have to be at (or have someone at) the console who can boot kernel.old (I stand open for correction, but last time I did it, 'twas that way). And, possibly, that person (you?) will also have to be able to do some other magic. Magic such as having other remote possibilities. DRAC access for example. But the phrase reinstall most of the system doesn't, at the very least, *sound* like the BSD Way(tm). Granted, sometimes it's quicker --- I know that's why it's used so often on that Other System ;-) If you have reinstalled a userland that depends on a kernel that doesn't boot, you are quite likely to be in trouble. I always do buildworld/installworld as part of my kernel build/installs. That is to ensure staying in sync. I reboot after the installworld then again after the installkernel. The BSD way does not necessarily involve easy recovery from making up procedures that haven't been worked out or tested by the release engineers. In fact, I don't think any operating system guarantees that you will have an easy time after making up your own upgrade procedures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
On Saturday 03 November 2007, Chris Haulmark said: Kevin Kinsey [EMAIL PROTECTED] writes: Lowell Gilbert wrote: Chris Haulmark [EMAIL PROTECTED] writes: Grant Peel wrote: I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. It's a good safety precaution; if your updated kernel won't boot, you will need to reinstall most of the system. That is over the board. Only times that I have made the mistakes in the past are: 1. Misconfiguring the kernel options such as disabling the meeded network driver built in the kernel. 2. Anything related to having kernel panics to occur. 3. Enabling firewall and getting locked out via network. That sounds a tad alarmist; if the new kernel won't boot, you'll have to be at (or have someone at) the console who can boot kernel.old (I stand open for correction, but last time I did it, 'twas that way). And, possibly, that person (you?) will also have to be able to do some other magic. Magic such as having other remote possibilities. DRAC access for example. But the phrase reinstall most of the system doesn't, at the very least, *sound* like the BSD Way(tm). Granted, sometimes it's quicker --- I know that's why it's used so often on that Other System ;-) If you have reinstalled a userland that depends on a kernel that doesn't boot, you are quite likely to be in trouble. I always do buildworld/installworld as part of my kernel build/installs. That is to ensure staying in sync. I reboot after the installworld then again after the installkernel. You should do it the other way around. That way if the new kernel doesn't boot you aren't stuck with an out of sync userland which may not play nicely with your old kernel. Also, depending on the changes booting an old kernel with a new userland may (and has) result in your system not booting at all. The proper sequence is: # make buildworld # make buildkernel # make installkernel # reboot # mergemaster -p # make installworld # mergemaster # reboot The BSD way does not necessarily involve easy recovery from making up procedures that haven't been worked out or tested by the release engineers. In fact, I don't think any operating system guarantees that you will have an easy time after making up your own upgrade procedures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/6.2R/announce.html --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.2.1 to 6.2 Migration.
But the phrase reinstall most of the system doesn't, at the very least, *sound* like the BSD Way(tm). Granted, sometimes it's quicker --- I know that's why it's used so often on that Other System ;-) If you have reinstalled a userland that depends on a kernel that doesn't boot, you are quite likely to be in trouble. I always do buildworld/installworld as part of my kernel build/installs. That is to ensure staying in sync. I reboot after the installworld then again after the installkernel. You should do it the other way around. That way if the new kernel doesn't boot you aren't stuck with an out of sync userland which may not play nicely with your old kernel. Also, depending on the changes booting an old kernel with a new userland may (and has) result in your system not booting at all. The proper sequence is: # make buildworld # make buildkernel # make installkernel # reboot # mergemaster -p # make installworld # mergemaster # reboot I prefer to do [build|install]world prior to building the kernel with the new installed tools. Even with an outsynced system, the most common tools to be affected are ps and top. Even when a kernel fails to boot all the way through, you can still rebuild a new kernel after booting with the old kernel. Having the new system tools will not hurt. The OP's primary goal was to discuss about if it was possible to upgrade 5.x to 6.x remotely via ssh. I provided that it was possible and what my method is. Chris The BSD way does not necessarily involve easy recovery from making up procedures that haven't been worked out or tested by the release engineers. In fact, I don't think any operating system guarantees that you will have an easy time after making up your own upgrade procedures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/6.2R/announce.html --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
I prefer to do [build|install]world prior to building the kernel with the new installed tools. Even with an outsynced system, the most common tools to be affected are ps and top. Even when a kernel fails to boot all the way through, you can still rebuild a new kernel after booting with the old kernel. Having the new system tools will not hurt. Am I wrong thinking that even when running an old system (kernel and tools) for the buildkernel step, only new tools (/usr/src/...) are being used? Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2.1 to 6.2 Migration.
Hi all, I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? if so ... 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? -Grant ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
At 11:56 AM 11/3/2007, Grant Peel wrote: Hi all, I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? if so ... 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? -Grant I did a source upgrade and rebuild from 5.1 to 6.1 remotely. Read upgrading carefully after you pull down the new src though for any extra steps you might need to make. However, also be prepared to make the trip should the upgrade go awry. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.2.1 to 6.2 Migration.
Hi all, I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. if so ... 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. Chris -Grant ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
Chris Haulmark [EMAIL PROTECTED] writes: Grant Peel wrote: Hi all, I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. if so ... 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. It's a good safety precaution; if your updated kernel won't boot, you will need to reinstall most of the system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
Lowell Gilbert wrote: Chris Haulmark [EMAIL PROTECTED] writes: Grant Peel wrote: I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. It's a good safety precaution; if your updated kernel won't boot, you will need to reinstall most of the system. That sounds a tad alarmist; if the new kernel won't boot, you'll have to be at (or have someone at) the console who can boot kernel.old (I stand open for correction, but last time I did it, 'twas that way). And, possibly, that person (you?) will also have to be able to do some other magic. But the phrase reinstall most of the system doesn't, at the very least, *sound* like the BSD Way(tm). Granted, sometimes it's quicker --- I know that's why it's used so often on that Other System ;-) Kevin Kinsey -- Only through hard work and perseverance can one truly suffer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 to 6.2 Migration.
Kevin Kinsey [EMAIL PROTECTED] writes: Lowell Gilbert wrote: Chris Haulmark [EMAIL PROTECTED] writes: Grant Peel wrote: I thought I would ask the question before I do it the hard way 1. Can FreeBSD be upgraded from 5.2.1 to 6.2 ? Yes. 2. Can it be done through an ssh connection, or MUST I make the trip to the farm and do it from the console? I've done 5.x to 6.x upgrades via ssh. It is possible. In the handbook, you will see mentions of booting into single user mode and I can tell you that it is not required. It's a good safety precaution; if your updated kernel won't boot, you will need to reinstall most of the system. That sounds a tad alarmist; if the new kernel won't boot, you'll have to be at (or have someone at) the console who can boot kernel.old (I stand open for correction, but last time I did it, 'twas that way). And, possibly, that person (you?) will also have to be able to do some other magic. But the phrase reinstall most of the system doesn't, at the very least, *sound* like the BSD Way(tm). Granted, sometimes it's quicker --- I know that's why it's used so often on that Other System ;-) If you have reinstalled a userland that depends on a kernel that doesn't boot, you are quite likely to be in trouble. The BSD way does not necessarily involve easy recovery from making up procedures that haven't been worked out or tested by the release engineers. In fact, I don't think any operating system guarantees that you will have an easy time after making up your own upgrade procedures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Scripts for UNIX/SAMBA to LDAP user migration?
Hello, I'm looking for some utilities for the migration and maintenance of UNIX/SAMBA users to OpenLDAP. I would like to have some tools/scripts creating well defined LDIF files for importation into LDAP. Any tips or hints? Thank you very much in advance, Oliver ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Scripts for UNIX/SAMBA to LDAP user migration?
On 2007-08-29 12:10, O. Hartmann wrote: I'm looking for some utilities for the migration and maintenance of UNIX/SAMBA users to OpenLDAP. I would like to have some tools/scripts creating well defined LDIF files for importation into LDAP. AFAIK, these are the usual scipts used for that: http://www.padl.com/OSS/MigrationTools.html -- Matthew Anthony Kolybabi (Mak) () ASCII Ribbon Campaign | Against HTML e-mail /\ www.asciiribbon.org | Against proprietary extensions ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Migration from 5.5 to 6.2 without single user access
On Tuesday 03 July 2007 21:10:22 Olivier Nicole wrote: Hi, I am upgrading a remote server (very remote, 10,000 km) and I have no way to access the machine in single user mode. Is there a recommended way to do the upgrade from 5.5 to 6.2? Do everything in multi-user, but kill all services but sshd? Thanks, Olivier your mileage may vary... but i do it without killing any services (but i also know that i am the only one logged into the machine). when you install world, *for the most part*, you are not tampering with things like apache, etc. as always, good backups of your data and configurations are a must before performing any such dangerous process as a multiuser-mode installworld. when going from 5.x to 6.x, most people recommend first upgrading to the lastest possible 5.x release first, and then moving on to 6.x (so in your case, either 5.5-STABLE or 5.5-RELEASE-p13. good luck, -- Jonathan Horne http://dfwlpiki.dfwlp.org [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Migration from 5.5 to 6.2 without single user access
On 7/4/07, Jonathan Horne [EMAIL PROTECTED] wrote: On Tuesday 03 July 2007 21:10:22 Olivier Nicole wrote: Hi, I am upgrading a remote server (very remote, 10,000 km) and I have no way to access the machine in single user mode. Is there a recommended way to do the upgrade from 5.5 to 6.2? Do everything in multi-user, but kill all services but sshd? Thanks, Olivier your mileage may vary... but i do it without killing any services (but i also know that i am the only one logged into the machine). when you install world, *for the most part*, you are not tampering with things like apache, etc. as always, good backups of your data and configurations are a must before performing any such dangerous process as a multiuser-mode installworld. when going from 5.x to 6.x, most people recommend first upgrading to the lastest possible 5.x release first, and then moving on to 6.x (so in your case, either 5.5-STABLE or 5.5-RELEASE-p13. good luck, -- Jonathan Horne http://dfwlpiki.dfwlp.org [EMAIL PROTECTED] Here how I did it for many remote servers I own and help friends to run. First install screen from the ports to make your life easier. After csup to the branch you desire to upgrade to, like RELENG_6_2 or RELENG_6 to get the latest changes in 6.x branch do these stuff. #rm -r /usr/obj/* #cd /usr/src #make cleanworld #mergemaster -p #make buildworld #make buildkernel #make installkernel #reboot #cd /usr/src #make installworld #mergemaster -iU (-iU added to automatically install files that don't exist and upgrade those that haven't changed. #reboot -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Migration from 5.5 to 6.2 without single user access
On Wed, 4 Jul 2007 22:44:34 +0300 Abdullah Ibn Hamad Al-Marri [EMAIL PROTECTED] wrote: On 7/4/07, Jonathan Horne [EMAIL PROTECTED] wrote: On Tuesday 03 July 2007 21:10:22 Olivier Nicole wrote: Hi, I am upgrading a remote server (very remote, 10,000 km) and I have no way to access the machine in single user mode. Is there a recommended way to do the upgrade from 5.5 to 6.2? Do everything in multi-user, but kill all services but sshd? Thanks, Olivier your mileage may vary... but i do it without killing any services (but i also know that i am the only one logged into the machine). when you install world, *for the most part*, you are not tampering with things like apache, etc. as always, good backups of your data and configurations are a must before performing any such dangerous process as a multiuser-mode installworld. when going from 5.x to 6.x, most people recommend first upgrading to the lastest possible 5.x release first, and then moving on to 6.x (so in your case, either 5.5-STABLE or 5.5-RELEASE-p13. good luck, -- Jonathan Horne http://dfwlpiki.dfwlp.org [EMAIL PROTECTED] Here how I did it for many remote servers I own and help friends to run. First install screen from the ports to make your life easier. After csup to the branch you desire to upgrade to, like RELENG_6_2 or RELENG_6 to get the latest changes in 6.x branch do these stuff. #rm -r /usr/obj/* #cd /usr/src #make cleanworld #mergemaster -p #make buildworld #make buildkernel #make installkernel #reboot #cd /usr/src #make installworld #mergemaster -iU (-iU added to automatically install files that don't exist and upgrade those that haven't changed. #reboot This is rather a sub-question than an answer: can Colin Percival's depenguinator (http://www.daemonology.net/depenguinator/) be used for such porpose? I mean, can someone run (or tweak) this program to run on an old remote FreeBSD installation in order to easily get a new fresh FreeBSD system? Nikola Lečić ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Migration from 5.5 to 6.2 without single user access
Hi, I am upgrading a remote server (very remote, 10,000 km) and I have no way to access the machine in single user mode. Is there a recommended way to do the upgrade from 5.5 to 6.2? Do everything in multi-user, but kill all services but sshd? Thanks, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password file migration
Ofloo wrote: I did the same thing a long time ago and i just created used pwd_mkdb, and it worked fine. Though i'm not entirely sure what this has to do with this topic. Mark Messier wrote: I know this has been covered before, but the search mechanism at the mailing list archive doesn't seem to work (zero matches for the word: password). I've got a 5.3 system and a 6.2 system. I want to migrate the user accounts from the 5.3 to the 6.2. They use different encryption mechanisms for the password in master.password. Other that running a cracker, is there a way to upconvert the old to the new? Thanks, -mark Simply running mergemaster (part of the recommended upgrade errata) should do the trick, as it will prompt you to execute some commands to 'upgrade' the password database and other relevant databases. -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password file migration
I did the same thing a long time ago and i just created used pwd_mkdb, and it worked fine. Though i'm not entirely sure what this has to do with this topic. Mark Messier wrote: I know this has been covered before, but the search mechanism at the mailing list archive doesn't seem to work (zero matches for the word: password). I've got a 5.3 system and a 6.2 system. I want to migrate the user accounts from the 5.3 to the 6.2. They use different encryption mechanisms for the password in master.password. Other that running a cracker, is there a way to upconvert the old to the new? Thanks, -mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/6to4-IPv6-problems-FreeBSD-6.2-p4-tf3829352.html#a11134620 Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
password file migration
I know this has been covered before, but the search mechanism at the mailing list archive doesn't seem to work (zero matches for the word: password). I've got a 5.3 system and a 6.2 system. I want to migrate the user accounts from the 5.3 to the 6.2. They use different encryption mechanisms for the password in master.password. Other that running a cracker, is there a way to upconvert the old to the new? Thanks, -mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password file migration
On Thu, Jun 14, 2007 at 02:57:41PM -0700, Mark Messier wrote: I know this has been covered before, but the search mechanism at the mailing list archive doesn't seem to work (zero matches for the word: password). I've got a 5.3 system and a 6.2 system. I want to migrate the user accounts from the 5.3 to the 6.2. They use different encryption mechanisms for the password in master.password. Other that running a cracker, is there a way to upconvert the old to the new? They are backwards compatible formats, so why do you want to change? If you are concerned that the old password hash is insecure (if it's an ancient DES password, this is true), then you will need to generate a new password for each affected account. One way to do this is by using password expiry to force a change on next user login (see e.g. pw(8)). Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Master Password File Migration.
Hi all, I cant seem to find a straight answer. Will $1$ passwords created (and currently used) in freeBSD 4.7 and 4.10 work when directly copied to 6.2? (i.e. will the unix users be able to login using thier regualr password, or will I have to reset them all?). -Grant ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Master Password File Migration.
On Sat, Feb 17, 2007 at 04:46:19AM -0500, Grant Peel wrote: Hi all, I cant seem to find a straight answer. Will $1$ passwords created (and currently used) in freeBSD 4.7 and 4.10 work when directly copied to 6.2? (i.e. will the unix users be able to login using thier regualr password, or will I have to reset them all?). Yes, they should work fine. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Master Password File Migration.
Thanks Erik! Here is the next big stumbling block. On the older servers, (4.7 and 4.10) we user apache with mod_ssl and run a seperate daemon for the ssl (443) connections. When we upgrade, will the certs and keys (created with 4.7 and 4.10) work using FreeBSD 6.2 and Apache 2.2 ? or will I need to redo all the keys, csrs and order new certs? -Grant - Original Message - From: Erik Trulsson [EMAIL PROTECTED] To: Grant Peel [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Saturday, February 17, 2007 5:09 AM Subject: Re: Master Password File Migration. On Sat, Feb 17, 2007 at 04:46:19AM -0500, Grant Peel wrote: Hi all, I cant seem to find a straight answer. Will $1$ passwords created (and currently used) in freeBSD 4.7 and 4.10 work when directly copied to 6.2? (i.e. will the unix users be able to login using thier regualr password, or will I have to reset them all?). Yes, they should work fine. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Master Password File Migration.
Hi, Grant Peel schrieb: Here is the next big stumbling block. On the older servers, (4.7 and 4.10) we user apache with mod_ssl and run a seperate daemon for the ssl (443) connections. When we upgrade, will the certs and keys (created with 4.7 and 4.10) work using FreeBSD 6.2 and Apache 2.2 ? or will I need to redo all the keys, csrs and order new certs? that should work also. Nothing changed in the way to create certificate for apache webserver. Kind regards, Oliver -- Oliver Koch Phone: +49-(0)5323-72-2626 Computer Center Fax:+49-(0)5323-72-3536 Clausthal University of Technology E-Mail: [EMAIL PROTECTED] Erzstraße 51 Web: http://www.rz.tu-clausthal.de 38678 Clausthal-Zellerfeld, Germany signature.asc Description: OpenPGP digital signature
Migration
Hi all, I have been perstering this list quite a bit lately asking all kinds of questions about how I am going to upgrade some old versions of FreeBSD (and add 1 brand new box), without having to reinstall each port/program an all servers causing all kinds of downtime. I may have answered my own question, but I would like to run the plan past y'all in case I am missing something. Everything I need to do may be possible by using the FreeBSIE Live CD that I am only now aware of even exists! Senario: I have 7 Servers, but this discussion only involves two older ones (to be upgraded), 1 new one (to be deployed), and 1 excellent one (that I want to clone). 1 old one had FreeBSD 4.7 1 old one has FreeBSD 4.10 1 brand new one has nothing. 1 Excellent machine has 6.2 RELEASE, and is in production. All of my servers use the same filesystems structures (/ /usr /var /home and /mnt (for the netowrk shares)). All servers are in the same location, All are connected to a WAN (via ethernet), All are connected to a VLAN (via ethernet). Another machine connected the same as above has a NFS share with lots of room. Steps: 1. Backup ALL data and put in a safe location :-) 2. Make complete file dumps of all filesystems on the machine that is to be cloned, 3. Using the live CD, create the needed file systems on the 'Blank' machine, 4. Connect the BLANK machine to the NFS machine IS THIS POSSIBLE USING THE LIVE CD? 5. restore the clone dumps to the BLANK machine, 6. Remove all previous machine and user specific config data from the newly loaded BLANK machine, 7 Make a new complete set of file dumps and save to the NFS machine, (skip to step 9 for the old machines). 8. Configure and use the blank machine. DONE (the rest below would only apply to the two OLD machines being upgraded), 9. Using the live CD, redo the drive repartition and disklabel newfs etc, to get pristine drives, 10. connect OLD machine to NFS. 10. Using the dumps made in step 8, load the new OS, 11. Using the backed up data from step 1, reload the /home, redo rc.conf, and a bunch of other user type data... 12. Test and fix the minor forget me nots (DONE) repeat steps 9-12 for other old machine. From what I can see, some of my virtual passwd files will still work (from 4.7 + 4.10 TO 6.2 COMMENTS? From what I can see, the master.passwd $!$ passwords should work from 4.7 + 4.10 to 6.2 COMMENTS? The old style mysql passwords should work as long as I am using the -OLD-PASSWORD option. ( I can redo the passwords if I have to anyways. Any comments from users who have used FreeSBIE would be greatly appreciated. -Grant . ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
Norberto Meijome wrote: On Thu, 23 Mar 2006 14:47:54 + Wayne [EMAIL PROTECTED] wrote: Also another thing that I was thinking about since my original mail, things like chkconfig and commands like say 'service network restart'. Does such a thing like a redhat layer type project exist so that emgineers who must convert to freebsd have as much of the day to day commands available to them while retraining? RHE has its ways, fbsd has others. it's not that hard to carry over really...you can make an simple cheatsheet for your engineeres. Or, see below. IMHO, it's quite simple in Freebsd: - if service is part of the base os, script is located in /etc/rc.d - if service is something you have installed, it's located in /usr/local/etc/rc.d Likewise, configuration for base services go in /etc, configuration for ports goes in /usr/local/etc/ ( If you can't tell what is part of the base OS or what is added...you may have other issues at hand :) ) Since you don't have the SysV style scripts in BSD, what gets run (base-system or added-from-ports) is defined in /etc/rc.conf (default options for base services are in /etc/defaults/rc.conf . options for services from ports are usually in the port documentation or the startup script) Regardless of this, scripts in either /etc/rc.d or /usr/local/etc/rc.d/ take the same params as RHE : start, stop, restart, status (+ custom ones in some services/ports). so 'service network restart' = /etc/rc.d/netif restart Very good --- and, to ease transition: echo alias 'service network restart' echo 'Did you mean /etc/rc.d/netif restart?' ~/.cshrc Of course, two issues: shell globbing and the fact that they'll be expecting bash. Probably the former is of more consequence, as neither sh/bash nor csh/tcsh seem to want to accept spaces in commands. Bash is available in ports, so using it for wheel level accounts should be fine; the OP should be cautioned about replacing root's shell, though (Bad Idea(tm), AFAIK). Nonetheless, it might be a good idea to hack together some kind of reminder script for some of the RH commands; note, as a somewhat related example, how many FTPD's accept both ls and dir You could (and I have, before) alias RHcommand FBSDequivalent, but that ends up not teaching anybody anything, and adds a layer of murk between the user and the OS; a layer that is not needed and detrimental for the most part. Shouldn't take any major corporate effort, and could be quite helpful. My $0.02, Kevin Kinsey -- My favorite sandwich is peanut butter, baloney, cheddar cheese, lettuce and mayonnaise on toasted bread with catsup on the side. -- Senator Hubert Humphrey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
On Sun, 02 Apr 2006 12:40:21 -0500 Kevin Kinsey [EMAIL PROTECTED] wrote: Nonetheless, it might be a good idea to hack together some kind of reminder script for some of the RH commands; note, as a somewhat related example, how many FTPD's accept both ls and dir You could (and I have, before) alias RHcommand FBSDequivalent, but that ends up not teaching anybody anything, and adds a layer of murk between the user and the OS; a layer that is not needed and detrimental for the most part. nice one... /usr/ports/sysutils/rh-transition ? :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
On Thu, 23 Mar 2006 14:47:54 + Wayne [EMAIL PROTECTED] wrote: Also another thing that I was thinking about since my original mail, things like chkconfig and commands like say 'service network restart'. Does such a thing like a redhat layer type project exist so that emgineers who must convert to freebsd have as much of the day to day commands available to them while retraining? RHE has its ways, fbsd has others. it's not that hard to carry over really...you can make an simple cheatsheet for your engineeres. IMHO, it's quite simple in Freebsd: - if service is part of the base os, script is located in /etc/rc.d - if service is something you have installed, it's located in /usr/local/etc/rc.d Likewise, configuration for base services go in /etc, configuration for ports goes in /usr/local/etc/ ( If you can't tell what is part of the base OS or what is added...you may have other issues at hand :) ) Since you don't have the SysV style scripts in BSD, what gets run (base-system or added-from-ports) is defined in /etc/rc.conf (default options for base services are in /etc/defaults/rc.conf . options for services from ports are usually in the port documentation or the startup script) Regardless of this, scripts in either /etc/rc.d or /usr/local/etc/rc.d/ take the same params as RHE : start, stop, restart, status (+ custom ones in some services/ports). so 'service network restart' = /etc/rc.d/netif restart etc ( I realise you probably know all this, but i have been asked this quite a few times...so I might as well put it down for the archives :) Hope it helped someone :) Best, Beto ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Linux migration
Hey Guys, Can anybody point me to some good resources on mingrating from Linux to FreeBSD? Since the threads issue which would have had detrimental effects on MySQL on FreeBSD has been sorted out with FreeBSD 5 we are looking at the possibility of migrating from RHEL to FreeBSD for our web services. Does anybody have any links to some good resources on migration from Linux to FreeBSD, I know google is my friend but I was hoping that some folks on here might have an idea of 'best of' that I can use for presenting the case... Thanks, Wayne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
On 3/23/06, Wayne [EMAIL PROTECTED] wrote: Hey Guys, Can anybody point me to some good resources on mingrating from Linux to FreeBSD? Since the threads issue which would have had detrimental effects on MySQL on FreeBSD has been sorted out with FreeBSD 5 we are looking at the possibility of migrating from RHEL to FreeBSD for our web services. Does anybody have any links to some good resources on migration from Linux to FreeBSD, I know google is my friend but I was hoping that some folks on here might have an idea of 'best of' that I can use for presenting the case... Thanks, Wayne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] It really depends. If your setup is exotic and complex, I dont think you will ever be able to find a guide. On the other hand, if your setup is simple (eg, PHP+Apache+MySQL, not clustered) then the migration is so simple, you wont even need a guide. Your best bet is to set up a box with FreeBSD, configure it to your liking, install the software you need, and just simply copy over the configuration files, database files and user files over to the FreeBSD box. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
Daniel A. wrote: On 3/23/06, Wayne [EMAIL PROTECTED] wrote: Hey Guys, Can anybody point me to some good resources on mingrating from Linux to FreeBSD? Since the threads issue which would have had detrimental effects on MySQL on FreeBSD has been sorted out with FreeBSD 5 we are looking at the possibility of migrating from RHEL to FreeBSD for our web services. Does anybody have any links to some good resources on migration from Linux to FreeBSD, I know google is my friend but I was hoping that some folks on here might have an idea of 'best of' that I can use for presenting the case... Thanks, Wayne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] It really depends. If your setup is exotic and complex, I dont think you will ever be able to find a guide. On the other hand, if your setup is simple (eg, PHP+Apache+MySQL, not clustered) then the migration is so simple, you wont even need a guide. Your best bet is to set up a box with FreeBSD, configure it to your liking, install the software you need, and just simply copy over the configuration files, database files and user files over to the FreeBSD box. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Here is a resource http://www.freebsdonline.com/index.php?option=com_contenttask=viewid=30Itemid=46 with all needed packages to run under your webserver CMS software like Mambo or Joomla. If you use other version than 5.4, the packages versions might differ, but you can find the correct version by ftping to freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
Hi Daniel, Thanks for your email. I have already done this, but I was looking more From the perspective of other companies who have done similar, case studies type things. Would help me out a great deal with my presentation. Also another thing that I was thinking about since my original mail, things like chkconfig and commands like say 'service network restart'. Does such a thing like a redhat layer type project exist so that emgineers who must convert to freebsd have as much of the day to day commands available to them while retraining? Higher ups like knowing things will be as smooth as possible and most of the inhouse experience is with RHEL so I don't want to end up lumping a lot of extra work on the people with freebsd experience... Thanks, Wayne On 23/03/2006 14:35, Daniel A. [EMAIL PROTECTED] wrote: On 3/23/06, Wayne [EMAIL PROTECTED] wrote: Hey Guys, Can anybody point me to some good resources on mingrating from Linux to FreeBSD? Since the threads issue which would have had detrimental effects on MySQL on FreeBSD has been sorted out with FreeBSD 5 we are looking at the possibility of migrating from RHEL to FreeBSD for our web services. Does anybody have any links to some good resources on migration from Linux to FreeBSD, I know google is my friend but I was hoping that some folks on here might have an idea of 'best of' that I can use for presenting the case... Thanks, Wayne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] It really depends. If your setup is exotic and complex, I dont think you will ever be able to find a guide. On the other hand, if your setup is simple (eg, PHP+Apache+MySQL, not clustered) then the migration is so simple, you wont even need a guide. Your best bet is to set up a box with FreeBSD, configure it to your liking, install the software you need, and just simply copy over the configuration files, database files and user files over to the FreeBSD box. -- ** Email Scanned by Elive's Virus Scanning Service - http://www.elive.net ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux migration
Hi Daniel, Thanks for your email. I have already done this, but I was looking more From the perspective of other companies who have done similar, case studies type things. Would help me out a great deal with my presentation. Also another thing that I was thinking about since my original mail, things like chkconfig and commands like say 'service network restart'. Does such a thing like a redhat layer type project exist so that emgineers who must convert to freebsd have as much of the day to day commands available to them while retraining? If you really want to run in RedHat land, then just run RedHat. FreeBSD has its own tools - some of them with the same or similar name and some different that will do what you need just fine. But they won't turn FreeBSD in to RedHat. Probably it will be better. jerry Higher ups like knowing things will be as smooth as possible and most of the inhouse experience is with RHEL so I don't want to end up lumping a lot of extra work on the people with freebsd experience... Thanks, Wayne On 23/03/2006 14:35, Daniel A. [EMAIL PROTECTED] wrote: On 3/23/06, Wayne [EMAIL PROTECTED] wrote: Hey Guys, Can anybody point me to some good resources on mingrating from Linux to FreeBSD? Since the threads issue which would have had detrimental effects on MySQL on FreeBSD has been sorted out with FreeBSD 5 we are looking at the possibility of migrating from RHEL to FreeBSD for our web services. Does anybody have any links to some good resources on migration from Linux to FreeBSD, I know google is my friend but I was hoping that some folks on here might have an idea of 'best of' that I can use for presenting the case... Thanks, Wayne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] It really depends. If your setup is exotic and complex, I dont think you will ever be able to find a guide. On the other hand, if your setup is simple (eg, PHP+Apache+MySQL, not clustered) then the migration is so simple, you wont even need a guide. Your best bet is to set up a box with FreeBSD, configure it to your liking, install the software you need, and just simply copy over the configuration files, database files and user files over to the FreeBSD box. -- ** Email Scanned by Elive's Virus Scanning Service - http://www.elive.net ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]