[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150111153710.GA23534@gremlin.ru>
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.
