Re: [Vserver] vserver + grsec + gradm problem
Dariush Pietrzak, by your words it's imposible to use vs+grsec with gradm on main system? Why then there are some patches vs+grsec? And why did I drive the car with pedals? Because it's fun. Ohn, and you get great mpg, although I never drove it more then a mile or so. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 We're giving you a new chance in life, and an opportunity to screw it up in a new, original way. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] FreeVPS Release 1.2 is available now
People! We released a new version of FreeVPS. Changes between 1.2RC2 and 1.2-RELEASE: 1. fixed few bugs in diskquota 2. fixed a bug in destroying virtual root device 3. fix some bugs in compiling kernel on RedHat Fedora Core 1 New features in version 1.2: 1. FreeVPS ported to RedHat Enterprise Linux AS 3.0 (kernel 2.4.21-x). Now we support both RedHat 7.3 and RedHat EL AS 3.0. FreeVPS kernel can work on other systems, but it's not tested and probably other systems need to update glibc. 2. New VPS memory accounting. 3. Virtual Network Device Driver with internal configurable Traffic Shaper. 4. 2-level full-separated routing. 5. full-separated BSD process accouting. Also we released new FreeVPS Tools v1.2 with new configuration tool vifconfig and some additional utilities. You could get a new FreeVPS release: from Anonymous CVS: cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as login password is empty cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as co -r FREEVPS_1_2_RELEASE kernel from web: http://www.freevps.com/download/releases/ - sources of FreeVPS http://www.freevps.com/download/rpms/RH_EL - rpm set of freevps-kernel-1.2 http://www.freevps.com/download/rpms/RH_73 - rpm set for running freevps-kernel-1.2 in RedHat 7.3 successfully A new FreeVPS Tools you could get: from Anonymous CVS: cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as login password is empty cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as co -r tools_1_2 freevps-tools from web: http://www.freevps.com/download/releases/freevps-tools.tar.gz See http://www.freevps.com/cvs.html for more information how to get FreeVPS from cvs. -- Alexander Suvorov [EMAIL PROTECTED] Positive Software http://www.psoft.net ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] iptables POM extras repository
On Tue, 2004-03-30 at 09:51, Dariush Pietrzak wrote: http://strongboxlinux.com/files/linux-2.4.25sbl1/ vserver+POM+supermount+evfs+freeswan+a few other things Wow. Super patchset! For those of us slightly Linux challenged will a yup, and broken systrace on top. Very clever. I've been playing around with systrace, somewhat successfully. But, yes, it should come with the warning that it's not entirely as secure as it says it is. And, since the patch is split off, you don't need to apply it. google search for supermount, evfs, and freeswan help explain what and I wouldn't recommend freeswan for 2.4.25, it's not trivial to merge, and there already is openswan project that's in active development. This is for compatibility with some older systems. Not trivial to merge? I really didn't have much problem with it... mind you, I'm using a 2.0x version. As to the other stuff that's in there: evfs is an encrypted VFS level filesystem. It patches in a set of utilities in /usr/src/linux/evfs, and creates a binary, called efs that you use for mounting partitions. (efs /source/dir /dest/dir). There's a page on it, somewhere, at hysteria.sk... although the guy who wrote it is no longer actively maintaining it. I've got it on there because it's the only working VFS level encryption scheme I've used for linux, so I've been playing with it. The other semi working one is part of the FIST project - but, I've never had it work reliably (i.e. across a reboot, which is pretty sad). Supermount is a patch set to allow mounts on devices that don't exist yet ;) Do a search on that for relevant information and code snippets. Anyways, as usual, YMMV. Also, be warned: ALWAYS recompile iptables if you're going to use a POM enabled netfilter if your kernel BEFORE you reboot the box - as it will cause many firewall rules to fail, and thus may stop you from being able to get into the box! Cheers, Liam ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [RFC] Future Linux-Vserver Networking (Part 1)
Here's a bunch of thoughts on networking in linux-vserver.
The nice thing about the current linux-vserver interface is that it's
efficient. The packet only has to travel once through the network stack,
which makes it faster, especially when packets have to be rebuilt from
fragments.
The bad thing about the current linux-vserver interface is that the
current setup can break routing somewhat. This is mostly due to the way
that IP is limited: because you're limited to a particular IP, bound to
a particular network interface, there ends up being compatibility
problems if a particular route is on a different interface than the IP
is bound to - the box has difficulty determining how to send the packet
because it's souce address is wrong (more of a problem with NAT than
live IPs, granted).
Also, if your address changes, you have to restart each and every
process on the vserver. Many vserver services won't operate correctly if
you bind the vserver to 0.0.0.0 (for instance bind), and even the ones
that do get pretty persnickity if you change the IP that 0.0.0.0
represents.
Additionally, localhost doesn't work nicely. What if, for instance, I
wanted to have all the vservers connecting to a particular service on
the box. In the current situation, I have to bind the service to a
particular IP, and then have all the vservers connect to the service on
that IP. I can always manage that through DNS, but it's not ideal - it
would be nicer to have an IP that I could connect to locally, without
having to rely on a particular IP for the box.
--
It strikes me that there's 2 distinct categories of useage whern it
comes to networking on linux-vserver:
1) The virtual hosting camp that uses one or more live IPs to represent
each client; or
2) The security partitioning camp that shares the boxes IPs among the
vservers - sometimes IPs are shared, sometimes they're not.
Each camp requires different core functionality. The virtual hosting
camp wants:
1) Transparency: real ips that don't need translation
2) Simplicity: not having to set up internal networks, etc
3) Bind security: vservers shouldn't be able to disrupt other vservers
4) Traffic accounting: ability to easily see which vserver traffic is
coming from
5) Security partitioning: vserver should only be able to see it's own
traffic
6) Ability to quickly turn on/off vservers
The security partitioning camp requires:
1) Security partitioning: as above
2) Bind security: as above
3) Traffic accounting
4) Information security: the vserver should have as little information
as possible about the host computer be available.
5) Ability to quickly turn on/off vservers
6) Ability to have private communication between vservers (such as
partioning a mysql server from an apache server on the local box).
They don't really need it to be as simple or transparent as the virtual
hosting camp.
---
One possible scenario is the following. I'll work on a patch for
vserver-utils if anyone's interested in this:
1) Put a private IP and interface for the context using the dummy net
module
insmod -o new dummy
ip link set dev dummy0 address ff:ff:ff:ff:11:11
nameif ${vserver_name} ff:ff:ff:ff:11:11
ip addr add x.x.x.x/yy dev ${vserver_name}
# NB: Bringing the interface up isn't necessary: in fact, I recommend
against it, as it could affect routing.
The reason for making a named interface is transparency. Also, it allows
one quick command to bring down all IPs on the vserver:
ip addr flush dev ${vserver_name}
Then, if NAT is required for the IP you've assigned.
2) Assign that IP to be the vserver IP for the box.
echo IP=X.X.X.X /etc/vservers/mine.conf
3) Mark the traffic because it's coming from that IP.
iptables -t mangle -A PREROUTING -s x.x.x.x -j MARK --set-mark
${S_CONTEXT}
iptables -t mangle -A PREROUTING -d ext.ip -j MARK --set-mark
${S_CONTEXT}
4) SNAT outgoing traffic that you want to allow from that section.
iptables -t nat -A PREROUTING -m mark --mark ${S_CONTEXT} -j SNAT --to
ext.ip
5) DNAT incoming traffic that you want to allow to that section.
iptables -t nat -A POSTROUTING -m mark --mark ${S_CONTEXT} -j DNAT
--to x.x.x.x
6) Drop all external connections coming directly to the dummy ip:
iptables -t nat -A PREROUTING -d x.x.x.x -i eth0 -j DROP
That offers better security, because it specifically allows any incoming
traffic that may occur, as well as concealing the real IP from the
vserver, which can be useful from a security standpoint. As well, it can
facilitate having static private IP addresses for the vservers, and deal
with services that don't want to be advertized elsewhere. It's fairly
transparent, and it's easy to understand a configuration, because the
interfaces are properly labelled.
The downside of using this is that it could, I think, confuse services
that use multicast or broadcast, like slp or dhcp (I haven't tried these
in this type of setup).
So, what extra pieces would help make this scenario better?
Once simple piece would be a
Re: [Vserver] FreeVPS Release 1.2 is available now
tirsdag 30. mars 2004, 15:43, skrev Alexander Suvorov: New features in version 1.2: 1. FreeVPS ported to RedHat Enterprise Linux AS 3.0 (kernel 2.4.21-x). Now we support both RedHat 7.3 and RedHat EL AS 3.0. FreeVPS kernel can work on other systems, but it's not tested and probably other systems need to update glibc. 2. New VPS memory accounting. 3. Virtual Network Device Driver with internal configurable Traffic Shaper. 4. 2-level full-separated routing. 5. full-separated BSD process accouting. 3. is the one thing I miss most i linux-vserver... You FreeVPS guys - could you consider making your project distribution independant and using a vanilla kernel instead? Best regards Tor Rune Skoglund [EMAIL PROTECTED] ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] FreeVPS Release 1.2 is available now
No plans to do that. If anyone interested porting our changes to vanillaa kernel - we will help (with advises). Otherwise - we are pretty happy with RH kernels. Best, Igor Seletskiy Tor Rune Skoglund wrote: tirsdag 30. mars 2004, 15:43, skrev Alexander Suvorov: New features in version 1.2: 1. FreeVPS ported to RedHat Enterprise Linux AS 3.0 (kernel 2.4.21-x). Now we support both RedHat 7.3 and RedHat EL AS 3.0. FreeVPS kernel can work on other systems, but it's not tested and probably other systems need to update glibc. 2. New VPS memory accounting. 3. Virtual Network Device Driver with internal configurable Traffic Shaper. 4. 2-level full-separated routing. 5. full-separated BSD process accouting. 3. is the one thing I miss most i linux-vserver... You FreeVPS guys - could you consider making your project distribution independant and using a vanilla kernel instead? Best regards Tor Rune Skoglund [EMAIL PROTECTED] ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [RFC] Future Linux-Vserver Networking (Part 1)
[EMAIL PROTECTED] (Liam Helmer) writes:
One possible scenario is the following. I'll work on a patch for
vserver-utils if anyone's interested in this:
Ok, I implemented the first part of your suggestion into util-vserver[1];
for the second one (iptables), I am not sure how to realize it (especially
the removal of the rules).
The creation of the dummy devices is ugly and has races ('dummy0' is
used by every 'vserver ... start' instance which conflicts with the
parallel vserver startup). 'dummyctx' would be ideally but is not
supported by the kernel.
That offers better security, because it specifically allows any
incoming traffic that may occur, as well as concealing the real IP
from the vserver, which can be useful from a security standpoint.
NAT (different external and internal IPs) is usually a pain when you are
working with UDP based services (Talk, Kerberos) since the original IP
will be often transmitted in the packet data.
I can imagine problems with the hostname checking of SSL too so that the
external IP must have a PTR record for the vserver's hostname (and vice
versa).
I played a little bit with official IPs for the dummy devices and using
proxy-arp for it but run into some (unrelated) problems on my testmachine
(what means 'H' process-state under 2.6?). Currently, I do not have time
to investigate it further.
Enrico
Footnotes:
[1]
http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/scripts/vserver.functions.diff?r1=1.26r2=1.28
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [RFC] Future Linux-Vserver Networking (Part 1)
On Tue, 2004-03-30 at 20:27, Enrico Scholz wrote:
Ok, I implemented the first part of your suggestion into util-vserver[1];
for the second one (iptables), I am not sure how to realize it (especially
the removal of the rules).
I'll work on that one, 'cause it would be useful for me... I'll see if I
can get something that works OK. Basically, to be useful, it would have
to find ways of being very specific, and it would have to keep track of
the state of each rule, as well as having a way to flush all rules in
case of issues with it's state file, etc.
So, you put the changes in CVS? I'm using my own hacked version of
vserver right now, as I've been playing with some of my own designs.
The creation of the dummy devices is ugly and has races ('dummy0' is
used by every 'vserver ... start' instance which conflicts with the
parallel vserver startup). 'dummyctx' would be ideally but is not
supported by the kernel.
It is supported by the kernel - that's what the nameif line that I put
in there does. The only race state is before the dummy0 interface gets
renamed... and that could be solved by having the script do some kind of
interface locking while it changes the name, maybe?
That offers better security, because it specifically allows any
incoming traffic that may occur, as well as concealing the real IP
from the vserver, which can be useful from a security standpoint.
NAT (different external and internal IPs) is usually a pain when you are
working with UDP based services (Talk, Kerberos) since the original IP
will be often transmitted in the packet data.
Agreed, there's some things that will simply never work in that
scenario. Like I was saying, it's useful for security, but it's
definitely not simpler for setup. What it is simpler for, however, is
providing host-only services, as well as for dealing with boxes that
have dynamic ips. And, it allows boxes with smaller numbers of IPs to
still use ip layer security without the vserver's interfering with
eachother's listeners.
I can imagine problems with the hostname checking of SSL too so that the
external IP must have a PTR record for the vserver's hostname (and vice
versa).
I think the best way of dealing with this is either dynamically
generated host records, or a host database (like ldap) that keeps track
of everything.
I played a little bit with official IPs for the dummy devices and using
proxy-arp for it but run into some (unrelated) problems on my testmachine
(what means 'H' process-state under 2.6?). Currently, I do not have time
to investigate it further.
Fair. I'll play around with it as my time permits.
Cheers,
Liam
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] International conference
Title: Untitled Document May 11-15 - the international conference in Crimea Dear Ladies and Gentlemen: We would like to welcome you to the first international scientific conference on the following topic: Practical Aspects of the Land Law Realization in Ukraine: Peculiarities, Problems and Ways of Solving The conference is going to take place on May 11-15, 2004 in Yalta, the Autonomous Republic of Crimea, Livadiya With the adaptation of the new Land Code in Ukraine the right of land use has become the real investment opportunity for Ukrainian and foreign companies The basic themes to be discussed at the conference: 1.Land law in Ukraine: analysis, practice of usage perspective standard acts 2. Regulation of the land purchase and sale treaties. Acquisition of land by foreign individuals and legal entities 3. Legal regulation of usage and sale of agricultural land 4. Rent of land plots: practice of usage and gaps in the legislation, settlement of arguments Invited to participate: - representatives of the State Committee of Ukraine on Land Resources, - representatives of the Institute of Agriculture of the Ukrainian Academy of Agrarian Sciences (UAAS), - representatives of the Institute of Land Planning of the UAAS, - representatives of the Kyiv municipal administration of land resources, - representatives of the Agrarian Policy Ministry of Ukraine, - representatives of the Yalta municipal administration of land resources, - representatives of the Simferopol municipal administration of land resources, - representatives of the Verkhovna Rada (Parliament) of Ukraine Committee on agrarian policy issues, - representatives of the presidents administration, - deputies of Ukraine, - executive authorities, - heads of the state administrations and institutions of local governing, - heads of home and foreign companies, - independent experts. Location of the conference: Ukraine, the Autonomous Republic of Crimea, Yalta, Livadiya, the Livadiya palace. The Livadiya palace - the former summer residence of the last Russian emperor Nikolay 2 is the main place of interest in Yalta. At present its one of the most frequently visited palaces of the world. Livadiya architecture and parkland is one of the most prominent monuments of landscape architecture. This palace which belongs to Italian Renaissance architecture was designed by the prominent Yalta architect and academician Krasnov S.P. (18651939). The palace is surrounded by the ancient park which was laid out in 1835. Its the biggest park in Crimea, the area together with the nearby territory of Oreanda makes 160 hectares. Oreanda is the elite health resort which was the summer residence of the general secretary of the USSR Brezhnev and other soviet and communist leaders. At present the palace is the constant meeting place for the presidents of Ukraine and Russia. Residence of the participants: The health center Chernomorie in Livadiya is the most wonderful place of the south coast of Crimea. Its famous for the estates of the tsar family and ones of the tsar close ministers which were built here in the 19th century. The wonderful subtropical evergreen park of Livadiya fills the air with balsamic aromas and the sea wind adds the salubrious micro particles of the sea salts to the unique natural cocktail. The residents enjoy: a swimming pool with sea water, a billiard room, a gymnasium, a library, a hairdressers and beauty salons, post office, currency exchange office, railway and airline ticket offices, parking place. Participation fee for one person: 1200 The fee includes: Transfer: Simferopol Yalta - Simferopol Staying in de luxe suites. Full board (breakfast, dinner, supper) Participation in the conference Consultation Specially designed collection of materials CD with materials and information Crimea sightseeing tours (Vorontsovski Palace, horse rides to Ai-Petri, visiting the tasting room of the Massandra winery) Evening party for the participants Coffee-breaks Registration of the participants: Multichannel line will start working beginning with the
Re: [Vserver] [RFC] Future Linux-Vserver Networking (Part 1)
On Tue, Mar 30, 2004 at 05:26:45PM +, Liam Helmer wrote:
Here's a bunch of thoughts on networking in linux-vserver.
The nice thing about the current linux-vserver interface is that it's
efficient. The packet only has to travel once through the network stack,
which makes it faster, especially when packets have to be rebuilt from
fragments.
this is something I intend to preserve, as the (linux-)vserver
motto always was (and still is) at full speed!
The bad thing about the current linux-vserver interface is that the
current setup can break routing somewhat. This is mostly due to the way
that IP is limited: because you're limited to a particular IP, bound to
a particular network interface, there ends up being compatibility
problems if a particular route is on a different interface than the IP
is bound to - the box has difficulty determining how to send the packet
because it's souce address is wrong (more of a problem with NAT than
live IPs, granted).
interesting, where did you observe this? just because the
linux-vserver network code does not care about interfaces.
Also, if your address changes, you have to restart each and every
process on the vserver. Many vserver services won't operate correctly if
you bind the vserver to 0.0.0.0 (for instance bind), and even the ones
that do get pretty persnickity if you change the IP that 0.0.0.0
represents.
hmm, interesting too, as this should be handled.
Additionally, localhost doesn't work nicely. What if, for instance, I
wanted to have all the vservers connecting to a particular service on
the box. In the current situation, I have to bind the service to a
particular IP, and then have all the vservers connect to the service on
that IP. I can always manage that through DNS, but it's not ideal - it
would be nicer to have an IP that I could connect to locally, without
having to rely on a particular IP for the box.
agreed!
--
It strikes me that there's 2 distinct categories of useage whern it
comes to networking on linux-vserver:
1) The virtual hosting camp that uses one or more live IPs to represent
each client; or
2) The security partitioning camp that shares the boxes IPs among the
vservers - sometimes IPs are shared, sometimes they're not.
Each camp requires different core functionality. The virtual hosting
camp wants:
1) Transparency: real ips that don't need translation
2) Simplicity: not having to set up internal networks, etc
3) Bind security: vservers shouldn't be able to disrupt other vservers
4) Traffic accounting: ability to easily see which vserver traffic is
coming from
5) Security partitioning: vserver should only be able to see it's own
traffic
6) Ability to quickly turn on/off vservers
The security partitioning camp requires:
1) Security partitioning: as above
2) Bind security: as above
3) Traffic accounting
4) Information security: the vserver should have as little information
as possible about the host computer be available.
5) Ability to quickly turn on/off vservers
6) Ability to have private communication between vservers (such as
partioning a mysql server from an apache server on the local box).
They don't really need it to be as simple or transparent as the virtual
hosting camp.
interesting analysis, let me add another one:
the home camp, which want's to use many vservers
with one public ip, but doesn't care much about
security ;)
---
One possible scenario is the following. I'll work on a patch for
vserver-utils if anyone's interested in this:
1) Put a private IP and interface for the context using the dummy net
module
insmod -o new dummy
ip link set dev dummy0 address ff:ff:ff:ff:11:11
nameif ${vserver_name} ff:ff:ff:ff:11:11
ip addr add x.x.x.x/yy dev ${vserver_name}
# NB: Bringing the interface up isn't necessary: in fact, I recommend
against it, as it could affect routing.
The reason for making a named interface is transparency. Also, it allows
one quick command to bring down all IPs on the vserver:
ip addr flush dev ${vserver_name}
Then, if NAT is required for the IP you've assigned.
2) Assign that IP to be the vserver IP for the box.
echo IP=X.X.X.X /etc/vservers/mine.conf
3) Mark the traffic because it's coming from that IP.
iptables -t mangle -A PREROUTING -s x.x.x.x -j MARK --set-mark
${S_CONTEXT}
iptables -t mangle -A PREROUTING -d ext.ip -j MARK --set-mark
${S_CONTEXT}
4) SNAT outgoing traffic that you want to allow from that section.
iptables -t nat -A PREROUTING -m mark --mark ${S_CONTEXT} -j SNAT --to
ext.ip
5) DNAT incoming traffic that you want to allow to that section.
iptables -t nat -A POSTROUTING -m mark --mark ${S_CONTEXT} -j DNAT
--to x.x.x.x
6) Drop all external connections coming directly to the dummy ip:
iptables -t nat -A PREROUTING -d x.x.x.x -i eth0 -j DROP
That offers better security, because it specifically allows any incoming
traffic that may occur, as well as
Re: [Vserver] [RFC] Future Linux-Vserver Networking (Part 1)
On Tue, Mar 30, 2004 at 09:46:14PM +, Liam Helmer wrote:
On Tue, 2004-03-30 at 20:27, Enrico Scholz wrote:
Ok, I implemented the first part of your suggestion into util-vserver[1];
for the second one (iptables), I am not sure how to realize it (especially
the removal of the rules).
I'll work on that one, 'cause it would be useful for me... I'll see if I
can get something that works OK. Basically, to be useful, it would have
to find ways of being very specific, and it would have to keep track of
the state of each rule, as well as having a way to flush all rules in
case of issues with it's state file, etc.
So, you put the changes in CVS? I'm using my own hacked version of
vserver right now, as I've been playing with some of my own designs.
The creation of the dummy devices is ugly and has races ('dummy0' is
used by every 'vserver ... start' instance which conflicts with the
parallel vserver startup). 'dummyctx' would be ideally but is not
supported by the kernel.
actually it is, at least somewhat, 2.6 knows a numdummies=
argument, and some experimental patches of mine add enhanced
per chbind() dummy devices ... or allow to add 'another' one
on demand ...
It is supported by the kernel - that's what the nameif line that I put
in there does. The only race state is before the dummy0 interface gets
renamed... and that could be solved by having the script do some kind of
interface locking while it changes the name, maybe?
That offers better security, because it specifically allows any
incoming traffic that may occur, as well as concealing the real IP
from the vserver, which can be useful from a security standpoint.
NAT (different external and internal IPs) is usually a pain when you are
working with UDP based services (Talk, Kerberos) since the original IP
will be often transmitted in the packet data.
Agreed, there's some things that will simply never work in that
scenario. Like I was saying, it's useful for security, but it's
definitely not simpler for setup. What it is simpler for, however, is
providing host-only services, as well as for dealing with boxes that
have dynamic ips. And, it allows boxes with smaller numbers of IPs to
still use ip layer security without the vserver's interfering with
eachother's listeners.
I can imagine problems with the hostname checking of SSL too so that the
external IP must have a PTR record for the vserver's hostname (and vice
versa).
I think the best way of dealing with this is either dynamically
generated host records, or a host database (like ldap) that keeps track
of everything.
I played a little bit with official IPs for the dummy devices and using
proxy-arp for it but run into some (unrelated) problems on my testmachine
(what means 'H' process-state under 2.6?). Currently, I do not have time
to investigate it further.
hmm, I'd suggest not to search for the 'H' on the net,
as probably noone ever wrote about it yet ;)
'H' means 'on hold' and is, to be honest, my creation.
a task, not scheduled because the context bucket is empty
is put on hold, and not scheduled, until the bucket has
reached tokens_min, then it is scheduled again ...
Fair. I'll play around with it as my time permits.
keep us up to date, maybe we should chat a little on the
irc, tomorrow? ...
best,
Herbert
Cheers,
Liam
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
RE: [Vserver] vserver + grsec + gradm problem
Heh, normaly it's not needed to add +CAP_SYS_ADMIN to gradm, even it's not needed to set up ACLs for gradm at all. Because they are added by default and /sbin/gradm record in acls will return an error reporting about double definitions of /sbin/gradm. Seems I got stuck :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandino Araico Snchez Sent: Tuesday, March 30, 2004 2:27 PM To: [EMAIL PROTECTED] Subject: Re: [Vserver] vserver + grsec + gradm problem Justinas S. wrote: Hi Sandino, Thanks for your reply. Do you have any suggestions how I can solve my problem? More details: After (on main system - not vserver, after building kernel, compiling gradm and rebooting) # gradm -E # gradm -a Password: Could not open /proc/sys/kernel/grsecurity/acl open: Permission denied Kernel log shows this: Mar 30 09:31:47 alus2 kernel: grsec: From 192.168.1.2: use of CAP_SYS_ADMIN denied for (gradm:1374) UID(0) EUID(0), parent (bash:706) UID(0) EUID(0) (why it's denied? It never happens in grsec+gradm only) I have not much experience with ACLs but seems like you are dropping the CAP_SYS_ADMIN cappability at some point. I used 2 different patches of vs+grsec: http://www.sandino.net/parches/vserver/linux-2.4.25-grsec-1.9.14-vserver-1.26.patch.gz http://www.firehead.org/~jeffrey/linux-vserver/grsecurity-1.9.14-2.4.25-vs1.26.patch and message was the same. -- Sandino Araico Snchez -- Meln se comi las plumas ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] FreeVPS Release 1.2 is available now
On Tue, Mar 30, 2004 at 04:43:45PM +0300, Alexander Suvorov wrote:
People!
We released a new version of FreeVPS.
congratulations!
Changes between 1.2RC2 and 1.2-RELEASE:
1. fixed few bugs in diskquota
hmm, is this freevps specific, or general?
(btw, is there some changelog somewhere?)
2. fixed a bug in destroying virtual root device
again, might this be a bug in my code too?
3. fix some bugs in compiling kernel on RedHat Fedora Core 1
New features in version 1.2:
1. FreeVPS ported to RedHat Enterprise Linux AS 3.0 (kernel 2.4.21-x).
Now we support both RedHat 7.3 and RedHat EL AS 3.0.
FreeVPS kernel can work on other systems, but it's not tested
and probably other systems need to update glibc.
2. New VPS memory accounting.
3. Virtual Network Device Driver with internal configurable Traffic Shaper.
4. 2-level full-separated routing.
5. full-separated BSD process accouting.
Also we released new FreeVPS Tools v1.2 with new configuration tool
vifconfig and some additional utilities.
looks great, how do you people test and maintain freevps?
did a short comparison, just to get a feeling for it ...
patch lines chars hunks ins rem add
---
vs1.27 4795 150592 252 2166 2011965
freevps-1.2 33324 9640401512 122062109 10097
this is a huge amount of code, guess you are doing some
automated testing or something similar, maybe you want
to share some information ...
best,
Herbert
PS: script used for this was:
function count () {
gawk '
{ lines++; chars+=length($0) }
/^@@/ { hunks++ }
/^[+][^+]/ { ins++ }
/^[-][^-]/ { rem++ }
END { printf %7d %7d %7d %7d %7d %7d\n,
lines, chars, hunks, ins, rem, ins-rem; }
' $1;
}
You could get a new FreeVPS release:
from Anonymous CVS:
cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as login
password is empty
cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as co -r
FREEVPS_1_2_RELEASE kernel
from web:
http://www.freevps.com/download/releases/ - sources of FreeVPS
http://www.freevps.com/download/rpms/RH_EL - rpm set of freevps-kernel-1.2
http://www.freevps.com/download/rpms/RH_73 - rpm set for running
freevps-kernel-1.2 in RedHat 7.3 successfully
A new FreeVPS Tools you could get:
from Anonymous CVS:
cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as login
password is empty
cvs -d :pserver:[EMAIL PROTECTED]:/var/spool/cvs/freevps-rh-as co -r
tools_1_2 freevps-tools
from web:
http://www.freevps.com/download/releases/freevps-tools.tar.gz
See http://www.freevps.com/cvs.html for more information how to get FreeVPS
from cvs.
--
Alexander Suvorov [EMAIL PROTECTED]
Positive Software http://www.psoft.net
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Dummy device creation without race states
The creation of the dummy devices is ugly and has races ('dummy0' is
used by every 'vserver ... start' instance which conflicts with the
parallel vserver startup). 'dummyctx' would be ideally but is not
supported by the kernel.
I've attached what I was thinking, roughly. Yes, this is part of a much larger script... I'll share it with everyone when it's more complete.
One problem with this code is that there's no real way of dumping the vserver interfaces when you're done. I can't think of others off the top of my head, but they're probably there.
vstohex () {
[ -n $1 ] || return 1
local oct1=$((${1} / 256))
local oct2=$((${1} % 256))
local -a out=()
for seg in $oct1 $oct2 ; do
hex1=$(($seg / 16))
[ $hex1 = 15 ] hex1=f
[ $hex1 = 14 ] hex1=e
[ $hex1 = 13 ] hex1=d
[ $hex1 = 12 ] hex1=c
[ $hex1 = 11 ] hex1=b
[ $hex1 = 10 ] hex1=a
hex2=$(($seg % 16))
[ $hex2 = 15 ] hex2=f
[ $hex2 = 14 ] hex2=e
[ $hex2 = 13 ] hex2=d
[ $hex2 = 12 ] hex2=c
[ $hex2 = 11 ] hex2=b
[ $hex2 = 10 ] hex2=a
[EMAIL PROTECTED]
done
echo ${out[0]}:${out[1]}
}
if [ - ${BUILD_VSIF} ] ! ip link ls ${VSERVER_NAME} 2 /dev/null ; then
olddummylist=($(ip link ls | gawk '$2 ~ /^dummy/ {print $2}' | sed 's/:$//g' | sort))
insmod -o new dummy
newdummylist=($(ip link ls | gawk '$2 ~ /^dummy/ {print $2}' | sed 's/:$//g' | sort))
if [ [EMAIL PROTECTED] = [EMAIL PROTECTED] ] ; then
${LOGERROR} Sorry, no dummy support in kernel!
else
for nd in [EMAIL PROTECTED] ; do
for od in [EMAIL PROTECTED] ; do
[ $nd = $od ] continue 2
done
dummylock=/var/lock/vserver/.lock.${nd}
[ -f $dummylock ] continue
echo $$ $dummylock
hexend=$(vstohex ${S_CONTEXT})
mac=ff:ff:ff:ff:${hexend}
ip link set dev ${nd} address ${mac}
nameif ${VSERVER_NAME} ${mac} || ${LOGERROR} Problem setting up the dummy interface
rm -f ${dummylock}
break
done
fi
fi
if [ $BUILD_VSIF ] ; then
if ! ip link ls ${VSERVER_NAME} /dev/null 21 ; then
${LOGERROR} Dummy interface ${VSERVER_NAME} doesn't exist!
else
ip addr flush ${VSERVER_NAME}
for ipaddr in ${IPROOT} ; do
ip addr add dev ${VSERVER_NAME} $ipaddr
done
fi
fi
vstohex () {
[ -n $1 ] || return 1
local oct1=$((${1} / 256))
local oct2=$((${1} % 256))
local -a out=()
for seg in $oct1 $oct2 ; do
hex1=$(($seg / 16))
[ $hex1 = 15 ] hex1=f
[ $hex1 = 14 ] hex1=e
[ $hex1 = 13 ] hex1=d
[ $hex1 = 12 ] hex1=c
[ $hex1 = 11 ] hex1=b
[ $hex1 = 10 ] hex1=a
hex2=$(($seg % 16))
[ $hex2 = 15 ] hex2=f
[ $hex2 = 14 ] hex2=e
[ $hex2 = 13 ] hex2=d
[ $hex2 = 12 ] hex2=c
[ $hex2 = 11 ] hex2=b
[ $hex2 = 10 ] hex2=a
[EMAIL PROTECTED]
done
echo ${out[0]}:${out[1]}
}
if [ ${BUILD_VSIF} != ] ! ip addr ls ${VSERVER_NAME} 2
/dev/null ; then
dummylist=($(ip link ls | gawk '$2 ~ /^dummy/ {print $2}' |
sed 's/:$//g' | sort))
insmod -o new dummy
newdummylist=($(ip link ls | gawk '$2 ~ /^dummy/ {print $2}' |
sed 's/:$//g' | sort))
if [ [EMAIL PROTECTED] = [EMAIL PROTECTED] ] ; then
${LOGERROR} Sorry, no dummy support in kernel!
else
for nd in [EMAIL PROTECTED] ; do
for od in ${olddummylist} ; do
[ $nd = $od ] continue 2
done
dummylock=/var/lock/vserver/.lock.${nd}
[ -f $dummylock ] continue
echo $$ $dummylock
hexend=$(vstohex ${S_CONTEXT})
mac=ff:ff:ff:ff:${hexend}
ip link set dev ${nd} address ${mac}
nameif ${VSERVER_NAME} ${mac} || continue
rm -f ${dummylock}
break
done
fi
fi
if [ $BUILD_VSIF ] ; then
if ! ip link ls ${VSERVER_NAME} /dev/null 21 ; then
${LOGERROR} Dummy interface ${VSERVER_NAME} doesn't
exist!
else
ip addr flush ${VSERVER_NAME}
for ipaddr in ${IPROOT} ; do
ip addr add dev ${VSERVER_NAME} $ipaddr
Re: [Vserver] Dummy device creation without race states
On Wed, Mar 31, 2004 at 01:41:14AM +, Liam Helmer wrote:
The creation of the dummy devices is ugly and has races ('dummy0' is
used by every 'vserver ... start' instance which conflicts with the
parallel vserver startup). 'dummyctx' would be ideally but is not
supported by the kernel.
I've attached what I was thinking, roughly. Yes, this is part of a
much larger script... I'll share it with everyone when it's more
complete.
One problem with this code is that there's no real way of dumping the
vserver interfaces when you're done. I can't think of others off the
top of my head, but they're probably there.
vstohex () {
[ -n $1 ] || return 1
local oct1=$((${1} / 256))
local oct2=$((${1} % 256))
local -a out=()
for seg in $oct1 $oct2 ; do
hex1=$(($seg / 16))
[ $hex1 = 15 ] hex1=f
[ $hex1 = 14 ] hex1=e
[ $hex1 = 13 ] hex1=d
[ $hex1 = 12 ] hex1=c
[ $hex1 = 11 ] hex1=b
[ $hex1 = 10 ] hex1=a
hex2=$(($seg % 16))
[ $hex2 = 15 ] hex2=f
[ $hex2 = 14 ] hex2=e
[ $hex2 = 13 ] hex2=d
[ $hex2 = 12 ] hex2=c
[ $hex2 = 11 ] hex2=b
[ $hex2 = 10 ] hex2=a
[EMAIL PROTECTED]
done
impressive, but
printf %s:%02x eth0 12345
is a good solution too (for bash)
best,
Herbert
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] [RESOLVED] Re: sshd weirdness: PAM session setup failed[6]: Permission denied
I just spent hours learning how PAM works...
I found that this will happen if S_NICE is set to anything above 0, _and_
pam_limits.so is enabled (default on fedora core 1).
Looking at pam_limits.c, it has this code in setup_limits() which is
probably where the trouble happens:
if (uid == 0) {
[SNIP]
pl-priority = 0;
}
[SNIP]
status = setpriority(PRIO_PROCESS, 0, pl-priority);
if (status != 0) {
retval = LIMIT_ERR;
}
So it looks like pam_limits will try to set your priority to 0 if you're
root. (Should this be considered a pam_limits bug?)
So the solution is either:
1. not to use S_NICE
2. comment out pam_limits.so from both /etc/pam.d/sshd and
/etc/pam.d/system-auth
Grisha
On Mon, 8 Mar 2004, Gregory (Grisha) Trubetskoy wrote:
I saw this posting earlier on:
http://www.paul.sladen.org/vserver/archives/200309/0176.html
And I am seeing the same problem:
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM setting tty to /dev/pts/0
PAM session setup failed[6]: Permission denied
debug1: Calling cleanup 0x8059c20(0x8090c20)
debug1: session_pty_cleanup: session 0 release /dev/pts/0
Kernel 2.4.25, vserver 1.26 with ctx disk limit patches (though I don't
think that matters). The os both outside and inside the vserver is RH
Fedora 1.
I've found that a workaround is to restart sshd in the vserver after
starting it, e.g.:
# vserver blah start
[...]
# vserver blah exec service sshd restart
...but other than that I've spent quite a bit of time looking at things
and I can't find what's causing this problem. What might be the difference
between sshd being started from init, vs doing later?
Has anyone else seen this?
Thanks,
Grisha
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Dummy device creation without race states
On Wed, 2004-03-31 at 05:11, Herbert Poetzl wrote:
On Wed, Mar 31, 2004 at 01:41:14AM +, Liam Helmer wrote:
printf %s:%02x eth0 12345
Ooh, cool. That's much nicer. So, after fixing a couple of other bugs too, it should look more like this:
vstohex () {
[ -n $1 ] || return 1
local oct1=$((${1} / 256))
local oct2=$((${1} % 256))
printf %02:%02 ${oct1} ${oct2}
}
if [ -n ${BUILD_VSIF} ] ! /sbin/ip link ls ${VSERVER_NAME} /dev/null 21 ; then
olddummylist=($(/sbin/ip link ls 2 /dev/null | gawk '$2 ~ /^dummy/ {print $2}' | sed 's/:$//g' | sort))
insmod -o dummy-${VSERVER_NAME} dummy
newdummylist=($(/sbin/ip link ls 2 /dev/null | gawk '$2 ~ /^dummy/ {print $2}' | sed 's/:$//g' | sort))
if [[ [EMAIL PROTECTED] = [EMAIL PROTECTED] ]] ; then
${LOGERROR} Sorry, no dummy support in kernel!
else
for nd in [EMAIL PROTECTED] ; do
for od in [EMAIL PROTECTED] ; do
[ $nd = $od ] continue 2
done
dummylock=/var/run/vserver/.lock.${nd}
[ -f $dummylock ] continue
echo $$ $dummylock
hexend=$(vstohex ${S_CONTEXT})
mac=ff:ff:ff:ff:${hexend}
ip link set dev ${nd} address ${mac}
nameif ${VSERVER_NAME} ${mac} || ${LOGERROR} Couldn't set up interface ${VSERVER_NAME} correctly!
rm -f ${dummylock}
break
done
fi
fi
if [ $BUILD_VSIF ] ; then
if ! /sbin/ip link ls ${VSERVER_NAME} /dev/null 21 ; then
${LOGERROR} Dummy interface ${VSERVER_NAME} doesn't exist!
else
ip addr flush ${VSERVER_NAME}
for ipaddr in ${IPROOT} ; do
ip addr add dev ${VSERVER_NAME} $ipaddr
done
fi
fi
is a good solution too (for bash)
best,
Herbert
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
