Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Jan 2015 18:37:10 +0300
From: gremlin@...mlin.ru
To: owl-dev@...ts.openwall.com
Subject: Re: Re: [owl-users] Owl 3.1-stable

On 2015-01-11 17:55:08 +0300, croco@...nwall.com wrote:

 >> We could do exactly the opposite: make Owl smaller.
 >> That means, out-of-a-box it could be just a virtualization host
 >> (VPS+VDS) with SSH access and build system, and other packages
     ^^^^^^^
 >> could be installed (yes, I'd write this word here) from several
 >> repositories.

 > let me second this. Owl with its minimalistic ideology can be
 > of a certain value in the role of a hardware node that runs all
 > the services inside VZ containters.

... and KVMs: many people need virtualization for non-Linux systems.

For now, I've built and tested the Qemu for Owl: it requires nothing
special for building, and VDSes could be controlled using either
SSH|RDP|whatever, or via Qemu monitor (`man qemu`, look for -monitor
parameter, like: -monitor unix:${HOME}/vm/${VM}.sock,server,nowait
and try nc -U ${HOME}/vm/${VM}.sock).

 > BTW, in most situations there's only one ip address, and it takes
 > some effort to setup such system, with OpenVZ containter and static
 > NAT for public ports.

That's why I've introduced the ability to override the configuration
with a /etc/rc.d/rc.network script in recently published owl-startup
package: that allows creating the in-host LAN (with simple brctl) and
even join several such LANs together via cables and switches.

 > We can perhaps add value to the out-of-a-box system if we automatize
 > this kind of setup, may be with another module added to our 'setup'
 > utility: it could ask the user which private subnet (s)he wants to
 > use, e.g., 10.177.178.0/24,

Then:
brctl addbr lan
ip link set dev lan up
ip address add 10.177.178.123/24 dev lan

and:
vzctl set 12345 --ipadd 10.177.178.234

 > then let the user create OpenVZ containers, assign them addresses
 > (both from the private range and outside of it, in case there are
 > more than 1 ip) and specify what external ports to forward, and
 > where, and whether should containers be able to access Internet
 > on they own (being NAT'ed via the main address of the system).

I use another approach: besides all these, the HTTP and HTTPS are
NATed inside of a separate OpenVZ VPS running nginx - which, in
turn, forwards incoming requests to destination OpenVZ VPS or KVM
VDS, or just responds with static cointent from its' cache.

 > Such module can even be able to preserve the iptables' rules that
 > fall outside of its scope.

The idea of "preserving rules" for netfilter is stupid and dangerous:
it must be fully configured on every change (so, it has no "start" or
"stop" calls - only "restart"). Some people may like going to their
servers physically (by feet), but not me - instead, I always use

/etc/rc.d/rc.firewall.test && sleep 5m && /etc/rc.d/rc.firewall

Obviously, all my /etc/rc.d/rc.firewall scripts start with

iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD DROP
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.