[Erp5-users] Installation problem - missing template.cfg
Jean-Paul Smets
jp at nexedi.com
Sun Mar 18 13:47:40 CET 2012
H
> OK, requested ERP5 under Software, and from the next cron run of
> slapgrid it is building.
>
OK. You can also start the slapgrid-cp command through prompt.
>
> Networking / firewalling:
>
> My interpretation of adding a machine to a cloud system is that the
> shared storage is made available to the cloud. This implies two-way
> traffic, so incoming network requests. This would require that the
> local firewall permits incoming traffic to the node.
>
You are right.
The provisionning part of VIFIB is designed to be compatible with a NAT
environment and even with a VM and a userland network virtual interface
(in such case, IPv6 is provided through tunnels). The ideas come from
TioLive Grid (
http://www.dailymotion.com/video/xd7fy8_tiolive-grid-demo_tech). The
goal is to be able to install about any software or cluster of services
behind a NAT or on a corporate network and have all the parts configured
automatically. The current protocol is based on polling. It will
eventually migrate towards a form of long polling/web socket over HTTP
to accelerate things.
The services which are provisionned by VIFIB can communicate directly
and can keep on running even if VIFIB is down or no longer accessible
(at least this is the design goal). If all services are located behind
your firewall, then you do not need to change any rules in your
firewall. But if you want other services with a global IPv6 outside your
network to communicate with the services in your network, you will need
to open your firewall.
One use case could be the following: you can define in VIFIB which
friend you want to share your computer with. By sharing computer, you
can install on their server a replica of your ERP5 and they can use your
server to install a replica of their own applciation (ex. a Maria
database). The automated backup and replication process will need both
computers to be mutually accessible. You will then need to open your
firewall at list for the IPv6 range of your friend. All this is handled
independently of VIFIB. VIFIB tries to be as little intrusive as possible.
>
> You also mention this below -- 'One Global IPv6 address to
> interconnect all services'?
>
>
> Looking again, it seems slapgrid is hierarchical, slaves send requests
> to the master & the master never initiates communications with the slave.
>
Yes.
>
> Should incoming ipv6 traffic be permitted or not?
>
Only if you want other IPv6 services (ex. an IPv4 to IPv6 front end) to
access your ERP5 instance. Else no need.
>
> On the ipv4 side, what is the network in slapos.cfg used for -- the
> 10.0.0.0/16?
>
> ...
>
> I'm guessing that it's for a tunnel to internal VMs rather than
> anything external, but not at all clear.
>
> You can read this:
> http://www.slapos.org/wiki/osoe-Lecture.SlapOS.Extended/developer-Introducing.SlapOS.Architecture
>
> It explains. Each instance has:
> - one local IPv4 address so that any IPv4 software can be used
> - one global IPv6 address, to interconnect all services between
> different hosts
> - and use stunnel to forward IPv6 to IPv4 (so that two IPv6
> incompatible services can connect eachother through IPv6 in a secure way)
>
> I have read that, it is still not clear.
>
> If the ipv4 address or subnet given in slapos.cfg is for local access
> from other computers, surely it must be compatible with the local
> subnet addresses or any other local machine will try and route via
> it's default gateway, not to the slapos/erp5 machine?
>
It is not for local access from other computers. It is only for loopback
access ie. to provide a different IPv4 (non LAN) address to every
process without conflicting with anything else. It also provides a form
a local firewalling (ie. only those services forwarded by stunnel are
open to the world, and go through X509 athentication if needed).
>
> The slapos.cfg ipv4 option is allocating a large subnet. Assuming
> these addresses are for local instances, how should they relate to the
> existing site networks/subnets, if at all, or how should routing be
> arranged for local ipv4 to the 10. Network instances.
>
They should be independent (ie. no overlap)
>
> Other network queries --
>
> In the bridge setup, for a Production server, it mentions adding eth0
> to the bridge config then removing eth0 from other use:
>
> Please also take not that any interface added to a bridge should no
> longer be configured by the system. The configuration file for that
> interface should just be removed.
>
> This is confusing -- if eth0 is otherwise removed, the machine has no
> local connectivity??
>
The bridge is only required if you want to use services such as
qemu-kvm. For ERP5 it is not required. There is a new option not to use
a bridge (it will be added soon to documentation).
If you use the bridge, you do not need to use eth0 anylonger (as long as
eth0 is part of the bridge). All communication goes through the bridge.
It is possible also not to connect any interface to the bridge (useful
for a developer). Here is for example what I am doing for my own laptop:
brctl addbr slapbr0
#brctl addif slapbr0 eth0
ip l s dev slapbr0 up
ip a a dev slapbr0 fd00::1/64
It means that I am creating the bridge but I do not attach to any interface.
Then here is my configuration file (/etc/opt/slapos/slapos.cfg):
[slapos]
software_root = /opt/slapgrid
instance_root = /srv/slapgrid
master_url = https://slap.vifib.com
computer_id = COMP-179
key_file = /etc/opt/slapos/key
cert_file = /etc/opt/slapos/certificate
certificate_repository_path = /etc/opt/slapos/pki/
[slapformat]
computer_xml = /etc/opt/slapos/slapos.xml
log_file = /var/log/slapformat.log
partition_amount = 5
bridge_name = slapbr0
partition_base_name = slappart
user_base_name = slapuser
tap_base_name = slaptap
# You can choose any other local network which does not conflict with your
# current machine configuration
ipv4_local_network = 10.0.0.0/16
You can find my own configuration bellow.
> Mention of stunnel to connect with remote(?) ipv6 systems is also
> worrying.
>
> Any possible extra route (interface. Tunnel etc) for incoming network
> traffic should be documented so appropriate firewall rules can be
> implemented.
>
> -Eg. Is it purely local request->remote response, so a stateful
> firewall can be used, or will there be unsolicited remote requests --
> if so on what ports?
>
> The tunnel traffic may be encrypted, but without a firewall the
> machine is completely exposed and open from the other end of the
> tunnel (and anything accessing that machine).
>
It is your choice how you want the server to be used.
For example, I am myself willing that my own laptop or servers are
exposed to the world through IPv6 because it simplifies a lot
cooperation between people. This is how Internet was operated in the
early days, everyone having a global IPv4 address and doing some
configuration on his unix machine to define who was allowed or not to
connect (ie. share).
But you may also want to block any incoming traffic through a firewall
and only allow communication through IPv6 between servers on your local
area network. This use case is also covered because you can specify in
SlapOS requests something like "only use servers on my LAN to deploy my
ERP5 cluster".
> We've lost servers in the past due to bugs in ipv4 firewalls allowing
> malicious access. I do not believe it's safe to leave any form of
> external interface without a firewall that permits only required traffic.
>
This can be argued in both ways. Anyway, both use cases are possible
with SlapOS. Most corporate networks where SlapOS is deployed block
incoming traffic as you are doing.
My personal view is that it is more important to have many replicas of
data and applications in different places in the world and make this
replication process as easy as possible - ie. without having to ask
permission to a human being to add some rules to the firewall. When I
read the list of incidents on the Cloud ( http://iwgcr.wordpress.com/) I
tend to feel safer by knowing that my data and applications are
replicated somewhere, including somewhere I do not know.
Maybe VIFIB should provide some APIs so that firewall configuration
could be automated by the processes which are instantiated. This would
be an interesting proof of concept.
> Lastly (for now) -- trivia; vifib.net user data will not accept UK
> postal codes, it complains they are 'not integers'. UK postcodes are
> alphanumeric with a space before the last three characters, ie. M1
> 2AA, A12 4ZZ, DN11 1DD
>
Thank you so much.
Regards,
JPS.
>
> Regards,
>
> Robert.
>
>
>
> _______________________________________________
> Erp5-users mailing list
> Erp5-users at erp5.org
> https://mail.tiolive.com/mailman/listinfo/erp5-users
lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:1636991 erreurs:0 :0 overruns:0 frame:0
TX packets:1636991 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:324181240 (324.1 MB) Octets transmis:324181240
(324.1 MB)
slapbr0 Link encap:Ethernet HWaddr 02:71:7e:16:7f:d4
inet adr:10.0.245.209 Bcast:0.0.0.0 Masque:255.255.255.255
adr inet6: XXXX::XXXX/64 Scope:Global
adr inet6: XXXX::XXXX/64 Scope:Global
adr inet6: XXXX::XXXX/64 Scope:Global
adr inet6: fe80::44cb:95ff:feab:876/64 Scope:Lien
adr inet6: XXXX::XXXX/64 Scope:Global
adr inet6: XXXX::XXXX/64 Scope:Global
adr inet6: XXXX::XXXX/64 Scope:Global
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 B) Octets transmis:1566 (1.5 KB)
slaptap0 Link encap:Ethernet HWaddr 1e:44:46:f5:00:42
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
slaptap1 Link encap:Ethernet HWaddr 5e:9b:6c:e9:8c:20
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
slaptap2 Link encap:Ethernet HWaddr 2e:37:f1:d2:eb:bf
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
slaptap3 Link encap:Ethernet HWaddr 02:71:7e:16:7f:d4
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
slaptap4 Link encap:Ethernet HWaddr ba:d4:05:d9:98:c7
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 74:de:2b:e9:40:ea
inet adr:192.168.0.14 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: 2a01:e35:8aad:5eb0:76de:2bff:fee9:40ea/64 Scope:Global
adr inet6: fe80::76de:2bff:fee9:40ea/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:507007 erreurs:0 :0 overruns:0 frame:0
TX packets:285219 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:442895079 (442.8 MB) Octets transmis:58519015
(58.5 MB)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.tiolive.com/pipermail/erp5-users/attachments/20120318/2179b538/attachment-0001.htm>
More information about the Erp5-users
mailing list