Am 30.01.2015 um 19:32 schrieb hydra:
> By the way, you don't need to have it in /etc/ansible, feel free to have it
> anywhere.
Thanks for the reminder ... I know already ;)
On Fri, Jan 30, 2015 at 5:01 PM, Stefan G. Weichinger
wrote:
> On 29.01.2015 11:31, hydra wrote:
> > I haven't migrated to group_vars yet, so try and let us know ;)
>
> It took me a bit of fiddling but I think I figured it out.
>
> I had to get the directory structure correct ... now I have
>
> /
On 29.01.2015 11:31, hydra wrote:
> I haven't migrated to group_vars yet, so try and let us know ;)
It took me a bit of fiddling but I think I figured it out.
I had to get the directory structure correct ... now I have
/etc/ansible/inventories/group_vars/
with files like siteA, siteB, siteC ...
I haven't migrated to group_vars yet, so try and let us know ;)
On Thu, Jan 29, 2015 at 11:14 AM, Stefan G. Weichinger
wrote:
> On 29.01.2015 10:47, Tomas Mozes wrote:
>
> > Have your IPs listed in hosts-production.
> >
> > For each site create a file, like:
> >
> > site_A.yml
> > - hosts: site_
On 29.01.2015 10:47, Tomas Mozes wrote:
> Have your IPs listed in hosts-production.
>
> For each site create a file, like:
>
> site_A.yml
> - hosts: site_A
> roles:
> - ...
>
> site_B.yml
> - hosts: site_B
> roles:
> - ...
>
> Then create site.yml where you include site_A.yml and s
On 2015-01-29 09:43, Stefan G. Weichinger wrote:
sorry ... still a bit OT but maybe interesting for others as well:
Yesterday I started to modify the following ansible role to fit my
needs
and work with gentoo target hosts:
https://github.com/debops/ansible-dhcpd
I modified tasks/main.yml (
sorry ... still a bit OT but maybe interesting for others as well:
Yesterday I started to modify the following ansible role to fit my needs
and work with gentoo target hosts:
https://github.com/debops/ansible-dhcpd
I modified tasks/main.yml (use portage ... install iproute2 as well) and
edited
Am 19.01.2015 um 11:11 schrieb Stefan G. Weichinger:
> I might file the bug at b.g.o. .. going upstream seems a bit early ;-)
posted to their google-group and got pointed to the latest devel-branch
(equals to ** in our gentoo-world).
Works now, even in "mixed mode" (both systemd and openrc i
On 18.01.2015 09:25, Alan McKinnon wrote:
> My advice:
>
> Start with groups. If you find you need to have lots of "when"
> clauses to make the plays work across more than one distro, and the
> whens follow the same format, then you might want to split them into
> groups. Make for example a "gent
On 17/01/2015 23:29, Stefan G. Weichinger wrote:
> On 12.01.2015 17:46, Alan McKinnon wrote:
>
>> You'd have to define it yourself in your plays somewhere
>>
>> Several ways present themselves:
>>
>> - Group customers together by customer name and use the group name.
>>
>> - Define the customer di
On 12.01.2015 17:46, Alan McKinnon wrote:
> You'd have to define it yourself in your plays somewhere
>
> Several ways present themselves:
>
> - Group customers together by customer name and use the group name.
>
> - Define the customer directly in the inventory. Generally it isn't
> recommended
On 12/01/2015 17:10, Stefan G. Weichinger wrote:
> On 11.01.2015 17:36, Alan McKinnon wrote:
>
>> The trick is to use a system that guarantees you a unique "label" or
>> identifier for each host.
>>
>> Perhaps {{ customer_name }}/{{ hostname }} works?
>>
>> This would fail if you have two customer
On 11.01.2015 17:36, Alan McKinnon wrote:
> The trick is to use a system that guarantees you a unique "label" or
> identifier for each host.
>
> Perhaps {{ customer_name }}/{{ hostname }} works?
>
> This would fail if you have two customers with the same company name
> (rare, but not impossible)
On 12.01.2015 08:46, Tomas Mozes wrote:
> On 2015-01-11 22:06, Alan McKinnon wrote:
>>> Out of curiosity, "ansible-controlled files, sysadmin-controlled files"
>>> means that something is managed via ansible and something is done
>>> manually?
>>
>>
>> Yes
>
> Then it's clear why /etc is in git. I
On 2015-01-11 22:06, Alan McKinnon wrote:
Out of curiosity, "ansible-controlled files, sysadmin-controlled
files"
means that something is managed via ansible and something is done
manually?
Yes
Then it's clear why /etc is in git. Ideally one would not make manual
changes to systems managed
On 11/01/2015 19:41, Tomas Mozes wrote:
> On 2015-01-11 09:22, Alan McKinnon wrote:
>> On 11/01/2015 09:46, Tomas Mozes wrote:
>>> On 2015-01-10 23:11, Alan McKinnon wrote:
On 10/01/2015 21:40, Tomas Mozes wrote:
> Ansible is a not a backup solution. You don't need to download yo
On 2015-01-11 09:22, Alan McKinnon wrote:
On 11/01/2015 09:46, Tomas Mozes wrote:
On 2015-01-10 23:11, Alan McKinnon wrote:
On 10/01/2015 21:40, Tomas Mozes wrote:
Ansible is a not a backup solution. You don't need to download your
/etc
from the machines because you deploy your /etc to machi
On 11/01/2015 17:12, Stefan G. Weichinger wrote:
> And at keeping /etc in git:
>
> So far I made it a habit to do that on customer servers. Keeping track
> of changes is a good thing and helpful. I still wonder how to centralize
> this as I would like to have these, let's call them "profiles" in
On 11/01/2015 14:25, Rich Freeman wrote:
> On Sun, Jan 11, 2015 at 3:22 AM, Alan McKinnon
> wrote:
>> The reason I'm recommending to keep all of /etc in it's own repo is that
>> it's the simplest way to do it. /etc/ is a large mixture of
>> ansible-controlled files, sysadmin-controlled files, and
Am 11.01.2015 um 13:25 schrieb Rich Freeman:
> On Sun, Jan 11, 2015 at 3:22 AM, Alan McKinnon
> wrote:
>> The reason I'm recommending to keep all of /etc in it's own repo is that
>> it's the simplest way to do it. /etc/ is a large mixture of
>> ansible-controlled files, sysadmin-controlled files,
On Sun, Jan 11, 2015 at 3:22 AM, Alan McKinnon wrote:
> The reason I'm recommending to keep all of /etc in it's own repo is that
> it's the simplest way to do it. /etc/ is a large mixture of
> ansible-controlled files, sysadmin-controlled files, and other arbitrary
> files installed by the package
On 11/01/2015 09:46, Tomas Mozes wrote:
> On 2015-01-10 23:11, Alan McKinnon wrote:
>> On 10/01/2015 21:40, Tomas Mozes wrote:
>>
>>
>>> Ansible is a not a backup solution. You don't need to download your /etc
>>> from the machines because you deploy your /etc to machines via ansible.
>>>
>>> I was
On 2015-01-10 23:11, Alan McKinnon wrote:
On 10/01/2015 21:40, Tomas Mozes wrote:
Ansible is a not a backup solution. You don't need to download your
/etc
from the machines because you deploy your /etc to machines via
ansible.
I was also thinking about putting /etc in git and then deploying
On 10/01/2015 21:40, Tomas Mozes wrote:
> Ansible is a not a backup solution. You don't need to download your /etc
> from the machines because you deploy your /etc to machines via ansible.
>
> I was also thinking about putting /etc in git and then deploying it but:
> - on updates, will you updat
On 2015-01-09 10:25, Stefan G. Weichinger wrote:
Am 08.01.2015 um 19:29 schrieb Alan McKinnon:
The directory layout in the best practice page is indeed way more than
you need, it lists most of the directories in common use across a wide
array of deployments. In reality you create just the direc
On 09/01/2015 11:25, Stefan G. Weichinger wrote:
> Am 08.01.2015 um 19:29 schrieb Alan McKinnon:
>
>> The directory layout in the best practice page is indeed way more than
>> you need, it lists most of the directories in common use across a wide
>> array of deployments. In reality you create just
Am 08.01.2015 um 19:29 schrieb Alan McKinnon:
> The directory layout in the best practice page is indeed way more than
> you need, it lists most of the directories in common use across a wide
> array of deployments. In reality you create just the directories you need.
>
> Global stuff goes in the
Copy pasted into new thread as subject has changed:
Stefan said:
===
played around with ansible today and managed to get this working:
http://blog.jameskyle.org/2014/08/automated-stage3-gentoo-install-using-ansible/
I even forked his repo and added a load of features to my newly built
gentoo-sy
28 matches
Mail list logo
