-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alexander Gerasiov wrote:
> Micah Anderson wrote:
>> Hi,
>>
>> Alexander Gerasiov wrote:
>>
>>>> Package: util-vserver
>>>> Version: 0.30.210-10
>>>> Severity: normal
>>>>
>>>> Hi there.
>>>> I want to push main host's mysqld socket inside vserver.
>>>> So I think that the simplest way is to mount /var/run/mysqld from host
>>>> to /var/run/mysqld on vserver. But that forces /var/run/mysqld cleaning
>>>> on vserver's start.
>>>>
>>
>> The reason this happens is not because of util-vserver, or anything
>> related to vservers at all, but instead the Debian startup scripts which
>> clean /var/run on bootup and shutdown. The only way to fix this is to
>> alter your debian scripts not to do this.
> Nope. As I can see, you wrong here.
Have a look at /etc/init.d/mountall-bootclean, which calls
/etc/init.d/bootclean (or bootclean.sh in sarge), specifically the part
that cleans /var/run, and you will see that I am not wrong here:
case "$1" in
start|"")
# Clean /tmp, /var/lock, /var/run
/etc/init.d/bootclean
This script is called on boot-up and cleans out /var/run. This is a
debian startup script.
> I don't know how to debug vserver (cause even strace halts), but simple
> test (something like adding "echo $0" in all of init scripts) gave me
> the following:
> ====without /var/run/mysqld ro===
> # vserver bigfoot start
> rc
> inetd
> Starting internet superserver: inetd.
> cron
> Starting periodic command scheduler: cron.
> apache2
> Starting web server: Apache2.
> rmnologin
> stop-bootlogd
> bootlogd
I have a hard time believing that this is *all* the init scripts that
run during startup. Maybe only those that are run during run level 2,
but there are more run levels that happen during startup. In a normal
debootstrapped sarge vserver the initscripts that are run are quite a
lot more than the ones that you have listed above. As a result, I
conclude that your test is flawed and I am not convinced that I am wrong.
> =================================
> ====with /var/run/mysqld ro===
> # vserver bigfoot start
> chroot-shunlink("var/run/mysqld/mysqld.pid"): Read-only file system
> chroot-shunlink("var/run/mysqld/mysqld.sock"): Read-only file system
Yeah, this happens because the boot-clean scripts are run on boot-up and
they are trying to remove the .pid and the .sock file in /var/run. This
is to be expected, is not a bug, and is most assuredly not a bug in
util-vserver.
> Failed to start vserver 'bigfoot'
> ==============================
> So this isn't init scripts who fails.
How do you conclude this?
>> This fails because the Debian startup scripts need to be able to write
>> to /var/run, so they fail and thus the startup of that server fails.
> Sigh... No..
Sigh... Yes.
>>>> 2nd Am I wrong? May be there are better way to do the same thing (I'm
>>>> speaking not about mysql, I know that it's possible to use network
>>>> socket, but I want to use the same scheme for some other services, so
>>>> I'm interested in mounting something inside vserver with bind option.).
>>
>> The way I solved this was to have mysql listen on the private network
>> and then I contact it over the network, rather than through a socket. If
>> you want to use a socket, then you need to be putting that socket
>> somewhere other than /var/run.
> Now the 1st thing I want is to get clean reply from upstream:
> Is this possible to connect host and vserver via UNIX-socket as I did,
> or that's working but just because of bug and wouldn't work in future.
Yes, you can connect via sockets cross vservers. I know that Ola did not
know this is possible, but it is, and it is intentional. It is not a
security bug. The only way to get a socket from the host, or from
another vserver, into the filesystem of a vserver is through a
privileged manner. If you want to do this, you are allowed.
>> First of all this is not a bug in util-vserver. It is at most
>> a bug in mysql-server, but in this case it is not that either.
> No, it isn't. Mysqld works fine, the problems I have is in scripts wich
> clean /var/run on vserver start.
Where do you suppose these initscripts come from? They do not come from
util-vserver, they are debian provided initscripts. The functionality
that they provide (cleaning /var/run, cleaning /tmp) are designed to be
there, and are not bugs. You are trying to do something that these
scripts were not designed for. If you wish you can report a bug on those
scripts, but I assure you that the response you will get will not be
what you want.
>> * you can not communicate across vservers (or to main host that is
>> context id 0), using unix sockets.
Yes, you can.
>> You can not do that. Even if you create that socket for the vserver they
>> can not communicate. That is the main idéa about vservers that they
>> can not communicate with each other, except for the ways normal servers
>> can, like network.
Yes you can do this, they can communicate. However, this isn't the point.
>>> 2nd Am I wrong? May be there are better way to do the same thing (I'm
>>> speaking not about mysql, I know that it's possible to use network
>>> socket, but I want to use the same scheme for some other services, so
>>> I'm interested in mounting something inside vserver with bind option.).
>>
>> You need to use network sockets. That is the only way. If you want the
>> servers to communicate the way you want, then you do not want vservers,
>> but rather simple chrooted environments.
> Yes, chroot is fine, but it isn't so secure %) And it doesn't allow many
> other vserver features.
As I have said, and Ola has said, and you can go ask upstream as well to
also be told this: You have to either create the socket somewhere other
than in a location that gets auto cleaned; you need to modify your
initscripts so they don't auto-clean; you need to connect over a private
network, rather than a socket file. You seem to be wanting to choose
another option: report a bug on util-vserver. This makes no sense, and
isn't where the problem lies.
Micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEvjv79n4qXRzy1ioRAt6UAKCZZcxdB9pkjGAYHMTURHGVM6qpEQCfeUs7
cebW7ub76IPu3JRYH1KKeGc=
=Zc5k
-----END PGP SIGNATURE-----
