[debops-users] Future of debops-contrib
by Stuart Read
<snip discussion of php roles>
Thanks for the helpful pointers.
> I think that question deserves a more extensive discussion. I would like to
> see DebOps in Debian 'main' component of the Debian Archive at some point.
> That means that DebOps, at least the main project repository, should conform
> to the Debian Free Software Guidelines:
> https://www.debian.org/social_contract.html#guidelines
>
> Packages in the 'contrib' component usually depend on non-free software,
> either in Debian 'non-free' component or on external software. So how does
> that look if DebOps has roles that depend on non-free software? I believe that
> the same rules would apply, and that would force the DebOps package to be
> included in the 'contrib' component of the Debian Archive, so let's avoid
> that.
>
> But, the non-free roles and playbooks could be managed in a separate git
> repository. You could install that repository alongsite DebOps monorepo, say
> in ~/.local/share/debops/debops-contrib/; all there is is to update the
> 'debops' scripts to handle multiple playbooks at once and allow configuration
> of multiple role/playbook directories where the script points Ansible at.
>
> This would probably call for restructuring of the 'site.yml' playbook, so that
> not all roles are executed at once and runs can be faster. When the CLI
> supports selecting multiple playbooks to run, some more esoteric roles will
> probably be removed from the main playbook.
>
> Of course for this, an entire separate organization on GitHub is unnecessary;
> there could be just another repository, say, debops/debops-contrib, with
> similar usage patterns as the main repository. Fork it, add your roles to it,
> make a pull request.
I agree completely that the future separation should be based upon
suitability for Debian main/contrib in order to promote efforts to
package debops. I like the idea of using a separate git repo for that
as well.
Thanks for all your work.
Stuart
6 years, 9 months
[debops-users] usage of pki service - how to create new root ca
by Jan Kowalsky
Hi all,
I wondering how to use the pki service with debops. I read documentation
but actually it didn't answer all my questions ;-).
What I reallized: When setting up the first host with pki_enabled: True
(default) debops is generating a root certificate and a first
certificate for this host. Well. Since I want't to test if the pki
service is the right thing for us (at the moment we use an self scripted
internal completely offline CA) - of course the first root certificate
is not the one we will continue with.
So I tried to delete the pki directory on the ansible controller - and
thought the root certificate is generated again. But this is not the fact.
How is it possible to initialize a completely new certificate auhtority
while there are already hosts in the same ansible domain?
Is there any way to use already existent key pairs for root ca?
And still there is the problem that encfs on debian stretch isn't
working (but this is another story).
Thanks a lot and regards
Jan
6 years, 9 months
[debops-users] Tips for a new role
by Stuart Read
Hello,
I'm interested in trying my hand at making a role to install/configure a
photo-management software ( https://lychee.electerious.com/ if you're
curious). I have a couple of questions:
- What is the best role to use as an example of the new debops.php role
(and mariadb)? This is a pretty standard PHP/mysql kind of program.
- How are debops-contrib roles handled in the new monorepo future?
Thanks!
Stuart
6 years, 9 months
[debops-users] enable ip_forward in debops.sysctrl.
by Jan Kowalsky
Hi all,
I want to enable ip forwarding (ipv4/ipv6) for one host. I thought it
should be enough to set
sysctl__system_ip_forwarding_enabled: True
But it doesn't work.
I have to set instead:
sysctl__host_parameters:
'net.ipv4.ip_forward':
value: 1
comment: |
enable IPv4 traffic forwarding.
If I understand correctly, it's enabled/disabled through this rule in
the debops.sysctl role:
sysctl__hardening_map:
'net.ipv4.ip_forward':
value: 0
comment: |
Disable IPv4 traffic forwarding.
state: '{{ sysctl__system_ip_forwarding_enabled|bool |
ternary("absent", "present") }}'
'net.ipv6.conf.all.forwarding':
value: 0
comment: 'Disable IPv6 traffic forwarding.'
state: '{{ sysctl__system_ip_forwarding_enabled|bool |
ternary("absent", "present") }}'
[.....]
What do I wrong?
What I realized: I do not set
sysctl__system_ip_forwarding_enabled: True
at all, there is an entry:
net.ipv4.ip_forward = 1
set. If I don't set it there is no entry generated at all - which means
the default (on debian) is active which means "0".
Thanks and regards
Jan
6 years, 10 months
[debops-users] common playbook and disable ferm
by Jan Kowalsky
Hi all,
I'm new on the list and quite new to debops. But already i can say: it
seems to be a great tool for our purposes. Step by step I begin to
understand the main concept. While I first thougt the predifined
playbooks won't help us a much I found there are reasonable predifined
configurations. So there is definitely a benefit of using the common
playbook.
However, what doesn't fit to our needs is the default ferm firewall as
we use either firewalls on decidedly hosts or other firewall tools
(firehol).
In documentation and older mailing list posts I found the following
configuration possibilities:
ferm: False
ferm__enabled: False
The ferm: False doesn't work for me at all. The ferm_enabled: False
still installs ferm and generates rules but doesn't activate them.
So my question: is there any possibility to use the common (and other)
playbook without ferm and disable it completely?
Thanks and Regards
Jan
6 years, 10 months