Date: Thu, 13 Jan 2000 19:13:26 +0300 (MSK) From: "Aleksandr A.Babaylov" <babolo@links.ru> To: igor@physics.uiuc.edu (Igor Roshchin) Cc: ports@FreeBSD.ORG Subject: Re: Port-maintenance Message-ID: <200001131613.TAA24442@aaz.links.ru> In-Reply-To: <200001130530.XAA16752@alecto.physics.uiuc.edu> from "Igor Roshchin" at "Jan 12, 0 11:30:11 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Roshchin writes:
> Your scenario is probably good in some set of conditions,
> when you have all servers running pretty much the same set of ports,
> while I am talking about situation, when each machine has its own set
> of the ports, and therefore, we can consider each machine isolated
> from each other (otherwise, for you case, NFS would be even simpler)
NFS mount of /usr leed to server reliabity down.
When desktop /usr over NFS is good enough
Mobile rack with IDE drive is good enough for upgrade.
About different set of ports:
Are you system administrator for all of it?
So it is convinient to use similar set of ports on each
of your hosts. It costs nothing to have
zilions of ports installed even if not used.
And it costs much if you install every port on
every of your host only when realise that needed port is
not installed. Big overhead in ports tree, distfiles
and main - tips and tricks for ports to install.
> Besides, in many cases the systems and the ports are being
> upgraded while they are working (in the multiuser mode).
> In addition to that - that's done remotely.
It is safty enough to delete opened file and create new one
- both will be kept until close
for example you can delete and create httpd file while server is running.
Yes, some races presents when upgrade live system.
And databases can't be upgraded so simple.
> Again, as I pointed out to Will and some other people earlier,
> suggested changes are not based on _necessity_,
> but rather on _convinience_ (and elegance).
Yes, you a right, just my 0.02 to estimate
price of different ways
> Igor
>
>
>
> Aleksandr A.Babaylov wrote:
> > Igor Roshchin writes:
> > >
> > >
> > > Thanks, Will, for your response.
A
> > >
> > > (One can skip explanations and speculations and jump to SUMMARY)
> > >
> > > I completely agree that your scripts do most of the job
> > > (and I could have come up with something similar).
> > >
> > > However, (sorry for not being clear enough at the very beginning)
> > > my point is that doing it this way (manually) is
> > > a) NOT the most effective:
> > > - just imagine repeating all those scripts, manually typing in the ports
> > > names after getting them from the pkg list, on several machines.
> > > - imagine N (5, 10, 20) machines to do the complete cvsup of ports
> > > (time and load) ? NFS mounted /usr/ports sometimes is just not an option.
> > > - ..
> > I can't imagine any port mechanism better then simle copy I use
> > to mantain the problem you described.
> > I mantain ethalon system (at home) and copy /usr (without /usr/ports)
> > and /var/db/pkg
> > 2..4 GB in most cases.
> > Yes, data for databases, www hierarhy roots so on are OUT of /usr
> > (/var or own fs for such a load)
> > so only /usr/local/etc /usr/X11R6/etc and /usr/X11R6/lib/X11/app-defaults
> > must be saved from overwrite.
> > keep links /usr/X11R6/bin/X -> /etc/X -> /usr/X11R6/bin/{some server}
> > and keep ssh using /etc/ssh* instead of /usr/local/etc/ssh*
> > to not destroy system by copiing.
> >
> > some broken ports (BigBrother as examle) can't mantained
> > in such a way.
> >
> > Upgrade automatically impossible if your servers are under
> > productive load and you need some testbad befor ANY
> > upgrage if you dont want loose job :-)
> >
> > SUMMARY: no real need for most of proposal possibilities,
> > but it is interesting game.
> >
> > PS. sorry bad English
> >
> > --
> > @BABOLO http://links.ru/
> >
>
>
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001131613.TAA24442>