Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Dec 2002 22:05:36 -0500 (EST)
From:      Simon1 <simon1@server.simon1.net>
To:        Philip Hallstrom <philip@adhesivemedia.com>
Cc:        Greg Goodman <admin@fastserve.net>, <freebsd-questions@FreeBSD.ORG>
Subject:   Re: Virtual Private Servers/Jails
Message-ID:  <20021203214038.U471-100000@server.simon1.net>
In-Reply-To: <20021203173839.P94322-100000@cypress.adhesivemedia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> I run them for development servers.  oak is the physical box and runs
> postgresql.  I've got 4 jails running apache so each developer can have
> his own sandbox and can royally screw things up without affecting the rest
> of us.  Works awesome.

That's always useful. Like I said, I just never got the jails to speak to
each other. It might have had something to do with the specific setup I
had going. I no longer manage the webhosting I was using the jails in, but
I'll see if I can't get some time with one of my development boxes to play
with.  Postgres I've never used, MySQL on the other hand..

> I don't use quotas since this isn't for a commercial web hosting
> environment....

That's what I was using them for. All of the work I did with jails was
targeted towards that environment.

> > What I've found:
> > 1) Connecting (aka telnet, ftp, ssh) from one jail to another or even to
> > the physical host is supposed to work, but I was never able to make it

[snip]

> Works great for me... I can do all three b/n jails, host, and remote
> servers or any combination.  Also updating ports with cvsup and/or
> installing them with porteasy also works just fine.  Never tried using
> sysinstall.

I seem to be the only person unable to get it to go. I think it may have
had something to do with the firewall rules, but even allow any from any
didn't seem to have a big effect. Not sure if dummynet may have had
anything to do with it either, though I doubt it.

> Not realtime, but you could run a "du -hcs *" on the top level directory
> that holds the jails to get a count, then substract what a "bare" jail
> contains and this would give you a snapshot of how much space is being
> used.  Granted in a commercial environment your users could use as much as
> they want and then remove it before you run the script, but that's life :)

Realtime quotas are a must in web hosting. The stuff I've had users do was
incredible. At one point, there were no quotas except as you described
above. The amount of trouble that caused.. *shakes head*

Anything that has to scan the files works okay in smaller environments.
But when you break 10-20k accounts things really bog down.

> > with root in a jail can't trash the main system, they can still do a lot
> > of damage.
>
> They can?  How?  Other than destroying that jail and thus anything on that
> IP, they can't touch the rest of the system.. at least that's my
> understanding.  Please correct me if I'm wrong.

No, you can't mess with processes or files outside of the jail. However,
you can run processes which bring the system to its knees (think while(1)
{ fork; }  <--don't laugh, I'm not making this up. People really do
run commands like that "just to see what would happen")

Also, if someone doesn't know any better (or doesn't have an option) they
might put the jail on one of their main partitions. FreeBSD may still
function, but it gets unhappy when a drive is totally full. Should you
have anything running that needs to save state (think databases here)
you'll have some problems.

That's what I was thinking of when I wrote what I did. I should have
clarified that, sorry.

> Check out the following ports which do what you want with maybe the
> exception of #2, but maybe even that, I don't remember.
>
> jailer-1.1.1        Manage FreeBSD jail startup, shutdown and console
> jailutils-0.5.1     Several utilies for managing jails

I also saw a post made right after I composed mine with a JailAdmin tool
that looked very promising. I haven't used any of the tools above, but I'm
glad to see that many of my 'wishes' have already come true. =)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021203214038.U471-100000>