OpenVZ & shorewall. Did'nt work acl based on ip range.

Hello all,

It's my first letter on this list, and, my English is not very well.
Please take me indulgence
for grammar/syntax and over erorrs :))

It's cross-post (also, i send letter for shorewall mail list).

I have trouble for acl's of ip range. But, acl for one host (with ip
adress) work fine.
Please help me for make work acl/find erorr in acl.

Becouse I'm new shorewall user, and, not guru in VZ technology,
I maked test configuration on Virtual Mashine (VirtualBOX) with bridge network.

Prodaction OVZ server work with iptables, and I'm afraid destroy work
configuration.
Work, but not fine. I want simple create new subnetworks, DMZ and overs.

===========Scheme======================

Host system (simple desktop of Fedora 8 with network bridge and
VirtualBOX) ---> Guest System with openvz kernel ---> some Virtual
Private Servers.

I think, you may forgot about VirtualBOX, but, you need remember about
OpenVZ. Hardware hosts in LAN see virtual OpenVZ? becouse, it use
bridge
with host system, and, VPS servers see also. All work, if whorewall
with virtual OpenVZ disabled.

create CT with password

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

RE: create CT with password

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

RE: create CT with password

> postcreate script can then modify /etc/passwd and /etc/shadow.

attached is a modified postcreate script

- Dietmar

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

RE: create CT with password

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

VE on GFS/GFS2

Hi,
we was running OpenVZ kernel 2.6.18-53.1.19.el5.028stab053.14 (on a Red 
Hat 5.2) and using GFS, and works quite good.

After migrating to 2.6.18-92.1.13.el5.028stab059.3 we noticed gfs module 
didn't work, and we saw that other users had the same
problem, and that the solution is to return to previous version.

We have set up a new server with this last OpenVZ version and GFS2, and 
although  gfs2 module is load without problems, it seems
there are other issue related to gfs2 and devices access, getting the 
following message when trying to run a vzctl enter command:
"Unable to open pty: Invalid argument"
Also the problem has been confirmed by other users.

So, is there a prevision to solve this problems?
What is the right way at the moment? Old version with GFS? Will the gfs 
module work again in future releases?

Thanks in advance for your help

Frank
UPC - Terrassa - Spain

--

-- 
Aquest missatge ha estat analitzat per MailScanner
a la cerca de virus i d'altres continguts perillosos,
i es considera que està net.
For all your IT requirements visit: http://www.transtec.co.uk

Re: create CT with password

The only problem is the solution is not generic. In other words, we
can't know how different distros handle local users. It used to be
crypt(3) and /etc/passwd (later /etc/shadow) manipulation. Now everybody
uses PAM which can be configured in this or that way. For example, new
passwords are checked (by pam_cracklib) for minimum length etc. (see
pam_cracklib(8) for much more details). Also they could be stored in a
different ways (this applies to both storage and hashes), say use (or
not use) /etc/shadow, md5 or sha256 hash or even NIS (see pam_unix(8)
for more details).

Because of the above, the only reliable way is to run passwd --stdin
inside the container (somewhat less generic (?) and more low-level way
is to call pam_chauthtok(3) function from a C code -- this is what I
assume passwd does). Using 'passwd' is the only way to make sure we are
doing what we should, not ignoring local configuration, not
circumventing any local restrictions etc. Unfortunately we need to start
the VE in order to run passwd (just chroot()'ing is not enough secure).

So, what if you approach the problem in a different way? Is it possible
that you run 'vzctl set --userpasswd' *after* VE start?

Dietmar Maurer wrote:
>
> Attached is a patch which passes the password to the postcreate script:
>
>  
>
> VE_ROOTPASSWD .. plain text passwd
>
> VE_CROOTPASSWD .. crypted  passwd (md5)
>
>  
>
> postcreate script can then modify /etc/passwd and /etc/shadow.
>
>  
>
> what do you think?
>
>  
>
> - Dietmar
>
>  
>
> *From:* users-bounces@...
[mailto:users-bounces@...] *On
> Behalf Of *Dietmar Maurer
> *Sent:* Donnerstag, 06. November 2008 10:51
> *To:* users@...
> *Subject:* [Users] create CT with password
>
>  
>
> Hi all,
>
>  
>
> currently you need to use the following command to change the password
> inside a CT:
>
>  
>
> vzctl set CTID --userpasswd root:XXX
>
>  
>
> This starts/stop the CT if it is not already running.
>
>  
>
> That is OK unless you have preconfigured appliance templates which
> does some
>
> initialization at first startup. Let me explain:
>
>  
>
> 1.)    User create the CT: vzctl creat 777 --ostemplate name …
>
> 2.)    User set the password: vzctl set 777 --userpasswd root:XXX
>  (start/stop CT)
>
> 3.)    User starts the CT
>
>  
>
> As you see, there is a totally unnecessary start/stop action. Even
> worse, the container
>
> is not fully functional at that time because HOSTNAME, DOMAIN,… in not
> set before the
>
> container is started with “vzctl start”.
>
>  
>
> I wonder if it would be possible to add a  --userpasswd parameter to
> the ‘create’ command? Or maybe
>
> only a --rootpasswd option (because root is always a local user).
>
>  
>
> /etc/passwd and /etc/shadow should be easy to modify directly, or are
> there some distributions
>
> with unusual file formats?
>
>  
>
> - Dietmar
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users@...
> https://openvz.org/mailman/listinfo/users
>   

RE: create CT with password

> The only problem is the solution is not generic. In other words, we
> can't know how different distros handle local users. It used to be
> crypt(3) and /etc/passwd (later /etc/shadow) manipulation. Now
> everybody
> uses PAM which can be configured in this or that way. For example, new
> passwords are checked (by pam_cracklib) for minimum length etc. (see
> pam_cracklib(8) for much more details). Also they could be stored in a
> different ways (this applies to both storage and hashes), say use (or
> not use) /etc/shadow, md5 or sha256 hash or even NIS (see pam_unix(8)
> for more details).

I just thought my approach works in 99,99% of all cases, but maybe I am wrong.

> Because of the above, the only reliable way is to run passwd --stdin
> inside the container (somewhat less generic (?) and more low-level way
> is to call pam_chauthtok(3) function from a C code -- this is what I
> assume passwd does). Using 'passwd' is the only way to make sure we are
> doing what we should, not ignoring local configuration, not
> circumventing any local restrictions etc. Unfortunately we need to
> start
> the VE in order to run passwd (just chroot()'ing is not enough secure).
> 
> So, what if you approach the problem in a different way? Is it possible
> that you run 'vzctl set --userpasswd' *after* VE start?

And save the password in plaintext somewhere? (we do not want to start the
VM on create).

There is another problem with your suggestion. Assume we do:

vzctl start
vzctl set --userpasswd
vzctl stop

Unfortunately the stop will abort any initialization tasks which are
running in background (mysql database initialization for example).

Maybe we can generate a init script (stored inside the VE) which sets 
the password?

- Dietmar

RE: create CT with password

Is there are real world example where my approach does not work?

I check for /etc/shadow, and store as md5 - AFAIK the user is able to
login with that password on all distribution using pam_unix. If not, we can still
try to read and parse the pam configuration.

It will not work for nis, but that is a rare case. But nis requires a network anyways, 
so the current code also fails.

So how can I create a VM with a password? For example:

# vzctl create
# vzctl start
# vzctl set --password

can also fail because the network is not running when we execute the passwd 
command (vzctl start does not wait until the network is fully functional, and passwd requires
the network when it uses nis).

Or is that wrong?

- Dietmar

> > The only problem is the solution is not generic. In other words, we
> > can't know how different distros handle local users. It used to be
> > crypt(3) and /etc/passwd (later /etc/shadow) manipulation. Now
> > everybody
> > uses PAM which can be configured in this or that way. For example,
> new
> > passwords are checked (by pam_cracklib) for minimum length etc. (see
> > pam_cracklib(8) for much more details). Also they could be stored in
> a
> > different ways (this applies to both storage and hashes), say use (or
> > not use) /etc/shadow, md5 or sha256 hash or even NIS (see pam_unix(8)
> > for more details).
> 
> I just thought my approach works in 99,99% of all cases, but maybe I am
> wrong.

RE: create CT with password

And is it really possible to store the root password on NIS? What happen on
filesystem errors - usually single user mode ask for a password before fsck. But sure,
that can't happen within a container.

- Dietmar