Re: freebsd-update(8) under sparc64? Why is it not available?
Adam PAPAI
> You're the first one to ask in a while. Since our userbase is small,
> and developer time is limited, we've never set it up.
>
> Right now I'd just be happy if I can get all the major ports to work :-)
>
> mcl
If I can do something for this project, please tell me what to do :)
I have 2xNetra T1, 1xNetra X1, 1xFire V100, so I have some sparc64
machines to test/build if this could help.
--
Adam PAPAI
Adam PAPAI
Is this the reason why binary freebsd-update is not available for
sparc64 arch?
The only methods for upgrading sparc64 are reinstall or build from source?
--
Adam PAPAI
Mark Linimon
Marius Strobl
> You're the first one to ask in a while. Since our userbase is small,
> and developer time is limited, we've never set it up.
>
The last time this topic came up IMO there was quite some
interest in getting this running but the showstopper was that
cperciva@ said that a requirement for any platform supported
by freebsd-update(8) would be that the build server is able
to run buildworld in 1 hour at most (unfortunately I currently
just can't find that email). My 4x1.5GHz V440 I originally
intended for this purpose unfortunately still takes 72 minutes
last time I checked. I suspect a 8x1.2GHz V880 would be able
to meet this requirement but I simply can't afford the housing
for such a beast.
Ken, did the V880s at your university become available as
intended some time ago?
Marius
Ken Smith
Hash: SHA1
On 3/24/10 6:38 PM, Marius Strobl wrote:
> On Wed, Mar 24, 2010 at 02:57:09AM -0500, Mark Linimon wrote:
>> You're the first one to ask in a while. Since our userbase is small,
>> and developer time is limited, we've never set it up.
>>
>
> The last time this topic came up IMO there was quite some
> interest in getting this running but the showstopper was that
> cperciva@ said that a requirement for any platform supported
> by freebsd-update(8) would be that the build server is able
> to run buildworld in 1 hour at most (unfortunately I currently
> just can't find that email). My 4x1.5GHz V440 I originally
> intended for this purpose unfortunately still takes 72 minutes
> last time I checked. I suspect a 8x1.2GHz V880 would be able
> to meet this requirement but I simply can't afford the housing
> for such a beast.
I have none that are faster than 900MHz processors, and the
one with the most processors in it is 6x750MHz.
> Ken, did the V880s at your university become available as
> intended some time ago?
At the moment there are two - one being used by portmgr@
for package builds which is the 6x750MHz machine. The
other I do the monthly snapshots and release builds on,
it's 4x900MHz. This was its performance on the world
built of 7.3-RELEASE:
>>> World build started on Sat Mar 20 23:34:54 EDT 2010
>>> World build completed on Sun Mar 21 00:50:58 EDT 2010
- --
Ken Smith
- - From there to here, from here to | kens...@buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkurSrkACgkQ/G14VSmup/aDPACeM4Whnkrn2UfQys/22Y4qTCOa
7soAnAnjusO81m0q/9fvMBDTYR9LjUgj
=l35W
-----END PGP SIGNATURE-----
Craig Butler
Can we bend the rules a little ?? Who set the requirement of an hour ?
freebsd-update might be a good thing to have..
Cheers
Craig B
Marius Strobl
IIRC it was Colin who once mentioned that this was decided
by the Security Officers in order to be able to react to
high impact security issues affecting multiple branches in
a timely manner should the need ever arise. In any case
he should be the right person to talk to about this so I
CC'ed him.
Marius
Colin Percival
The can-buildworld-in-an-hour is a rough rule of thumb, but
it's pretty good. The issue here, as Marius said, is that we
want to be able to push out advisories promptly; this isn't a
problem when we're only dealing with one branch, but sometimes we
have issues which affects all the releases -- currently we support
{6.4, 7.1, 7.2, 7.3, 8.0}, which is a fairly typical set -- and
each run of patch builds requires two complete buildworlds plus
some other stuff (kernel builds, comparing bits between builds,
shuffling them around, building binary patches)... so I imagine
that a 1.5 hour sparc64 buildworld time would put us at over 24
hours for a complete set of patch builds. And that's not counting
the fact that every new FreeBSD release takes longer to build.
Some people have suggested in the past that we could do sparc64
update builds but not hold up advisories waiting for them -- but
I really don't like that option, since it would "train" people to
use binary updates rather than source updates, and the times when
they would need to wait -- time-sensitive security advisories --
are exactly the times when they shouldn't wait.
(As a side note, for obvious security reasons I don't want to add
hardware outside of the established FreeBSD.org datacenters for
this sort of thing.)
I think the best approach towards having FreeBSD Update support for
sparc64 is to get release cross-building working; that way we would
be able to use amd64 hardware, which I think we can safely assume
will continue to be available in ever-increasing speeds.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
John Baldwin
> I think the best approach towards having FreeBSD Update support for
> sparc64 is to get release cross-building working; that way we would
> be able to use amd64 hardware, which I think we can safely assume
> will continue to be available in ever-increasing speeds.
Err, release cross-building does work AFAIK. ru@ worked on it many years ago.
Have you tried it and run into problems?
--
John Baldwin
Colin Percival
> On Friday 26 March 2010 11:00:28 am Colin Percival wrote:
>> sparc64 is to get release cross-building working; that way we would
>> be able to use amd64 hardware, which I think we can safely assume
>> will continue to be available in ever-increasing speeds.
>
> Have you tried it and run into problems?
Cross-building "works" in the sense of finishing with something which looks
like a release; but when I tried it a few years ago (when I was writing the
current generation of freebsd-update) there were some files which built
differently for cross vs. native builds. IIRC it wasn't a huge number of
files, though.
Miles Nordin
cp> it would "train" people to use binary updates rather than
cp> source updates, and the times when they would need to wait --
cp> time-sensitive security advisories -- are exactly the times
cp> when they shouldn't wait.
hilarious.
wait, no yeah, actually Colin I have your security update list feeding
directly into my phone, and when one of your updates comes out I drop
whatever I'm doing and spin up my quad USIII cluster, which I keep
on-hand but powered off in a ``spare'' rack in lower Manhattan to
support my Netra X1 by running builds for me.
I keep thinking, oh, maybe I'll get rid of the ``spare'' rack, I'm not
sure. Or maybe I'll keep it. I can't decide. I could go either way.
I don't really even notice whether I keep it or not. I suppose if I
got into the habit of being trained to do binary upgrades of my X1 I
might notice the rack was unnecessary and ditch the four
power-guzzling 50kg machines inside it. Yeah, and that would be a
mistake, because it would leave the critical services on my X1
vulnerable for precious extra hours which evil hackers could use to
write sparc64 shell code and compromise critical pieces of
infrastructure!
good thinking, good thinking. I can always count on the crack team of
experienced blokes on the BSD project to forsee the unexpected. dunno
what I'd do without your valuable foresight.
Mark Linimon
> good thinking, good thinking.
I have to admit even on the second reading of your email, I can't make
sense of it.
mcl
Royce Williams
It's extended sarcasm.
Miles' point appears to be that some end users do not have the
resources necessary to set up a sufficiently beefy sparc64 build
system to respond quickly to security announcements.
But it could have been said in a more constructive manner.
For me, not having binary updates for sparc64 improves security -- but
not in the way that Colin describes. I would love to run FreeBSD on
my Ultra 30, but knowing how long it will take to build world in
response to a security issue has turned it into a very secure
paperweight under my desk. :-)
In my opinion, people who would run sparc64 on slow hardware facing
the public Internet without being willing and able to disconnect it
when something serious was announced are already doing other foolish
things ... and I'd rather not be punished for their bad behavior. :-)
I'd chip in $100 to fund either A) tracking down the remaining
cross-build issues, or B) adding I/O or CPU power to an existing build
setup.
Finally, to repeat a point that I made in the last big thread on this topic [1]:
"It may be that there's no way to break that 1-hour barrier. Maybe I
can convince Colin that, until full cross-compiling is available, we
sparc64 folks would settle for slightly-delayed binary security
updates (instead of never getting them at all). It's the very fact
that we're running on slower hardware that makes freebsd-update so
attractive."
Royce
1. http://lists.freebsd.org/pipermail/freebsd-sparc64/2007-February/004622.html
- Feb 2007
Royce Williams
> On Fri, Apr 9, 2010 at 7:52 PM, Royce Williams <royce.w...@gmail.com> wrote:
>> I'd chip in $100 to fund either A) tracking down the remaining
>> cross-build issues, or B) adding I/O or CPU power to an existing build
>> setup.
>
> revive his E4500s. Does anyone know if that ever happened? Maybe
> that's where my money could go.
Er, sorry - I just reread Colin's response; not sure how I missed
that. Half of my earlier post would have been unnecessary.
So it looks like cross-compiling is the way to go. Who else can chip
in to fund tracking that down? I'm in for $100. I can't make it to
BSDCan this year, so I've got to spend the money on something
FreeBSD-related. ;-)
Royce
Royce Williams
> cross-build issues, or B) adding I/O or CPU power to an existing build
> setup.
In that 2007 thread, Hiroki Sato said that he needed hardware or $ to
revive his E4500s. Does anyone know if that ever happened? Maybe
that's where my money could go.
Royce
Mark Linimon
> In that 2007 thread, Hiroki Sato said that he needed hardware or $ to
> revive his E4500s. Does anyone know if that ever happened?
We decommissioned two of the three. They were powered down more often
than not.
I have a V240 here in various pieces that I've bought off of eBay, but
I've not yet assembled and powered it up to see if it is sufficiently
fast to serve for this purpose. The most recent V210 that we just brought
up as a package building node (same flavor machine, different configuration)
seems heavily disk-bound. I don't know yet whether that is due to the
physical disks, or the setup of that machine. It's a dual 1GHz, 6G RAM,
which is the beefiest machine we've got.
I won't have the time to investigate disk performance before BSDCan but if
it turns out that it's the physical disks I'll be happy to take you up on
your offer and repurpose the machine.
mcl
Miles Nordin
rw> Miles' point appears to be that some end users do not have the
rw> resources necessary to set up a sufficiently beefy sparc64
rw> build system to respond quickly to security announcements.
Colin's position is totally ridiculous: people offer build resources
of exotic, heavy, power-hungry hardware to the FreeBSD project, which
already has scripts and frameworks for producing timely builds, but he
believes these offers are conterproductive because individual users
acting separately and without these resources will bumble their way
into developing their own scripts and frameworks to do updates much
faster, so long as they're not demobilized from this natural task
through ``training.'' Where does such implausible belief come from?
``I find the builds boring, and they're more trouble than you'd
think---please, someone else more interested do them, far away from
me'' strikes me as a fine reason to avoid mucking with a platform
that's twice as dead this year as it was last year, but the stated
reason is silly mind-twisting obstructionism, and I don't know how
anyone can get anything done when such beliefs come naturally.
rw> But it could have been said in a more constructive manner.
Not in my experience. It sounds like the argument's been going on for
several years, so restating the same position in a literal sense will
get a repetition of the same deluded responses, which is not
constructive at all.
The only thing I can think of more constructive might be, ``can I have
a copy of all your scripts, please. I'll do my own releases---I just
want a head-start on what few solved gotchya's with the build process
you've found, and then I'll alter the scripts to integrate with my
smart power strip to kick off builds from a work queue at bootup and
shut the machine off when the build finishes,'' but I would expect to
hear ``I will not give you the scripts because your having and using
them will train people to <blah blahblah SKIP blah blahblah SKIP
blah blahblah>.''
rw> people who would run sparc64 on slow hardware facing the
rw> public Internet without being willing and able to disconnect
rw> it when something serious was announced are already doing
rw> other foolish things
You would not believe how much foolish behavior there is on the
Internet, and updates are always a nightmare since regressions can
take down services just as well as security breaches. It's a
complicated issue.
But I have never heard anyone say, ``what we really need to push
security updates out faster and with fewer regressions, is fewer
automated update tools. Have everyone build 'em from source, with
'cvs update' and bmake. Yah, that's what'll tighten up our ship.''
it's totally crazy.
rw> "It may be that there's no way to break that 1-hour barrier.
rw> Maybe I can convince Colin that, until full cross-compiling is
rw> available, we sparc64 folks would settle for slightly-delayed
rw> binary security updates (instead of never getting them at
rw> all). It's the very fact that we're running on slower
rw> hardware that makes freebsd-update so attractive."
yeah, what you said, three years ago.
good luck, everyone.
Mark Linimon
> Colin's position is totally ridiculous: people offer build resources
> of exotic, heavy, power-hungry hardware to the FreeBSD project, which
> already has scripts and frameworks for producing timely builds, but he
The problem is that we're effectively guaranteeing that bits pushed out
via freebsd-update are secure. Our traditional view is that machines
that are loaned to us aren't sufficiently secure for us to be able to
stand behind that guarantee.
Right now the machines used to produce those bits are dedicated to that
purpose and that purpose only, and are physically and logistically
secure.
If someone wants to donate a sufficiently capable sparc64 machine to the
project that can be installed under similar constraints, I'm all ears.
Right now we don't have one.
mcl