Thanks, I'll give that a shot.
I don't like the "explicitly sets all the flags that are reported by
ansible_mount" feature either so I might have to think about this more.
I guess I could note which mounts are missing "nodev", then use the
lineinfile: to rewrite the affected /etc/fstab lines and add the "nodev"
flag. (That's about 33% serious, 66% tongue-in-cheek...)
Something like:
- name: "Setup some of the mount flag variables"
set_fact:
mount_flags:
- 'nodev'
- 'noexec'
mount_point:
- 'mount01'
- 'mount02'
- name: "Ensure mount flags are set"
lineinfile:
path: /etc/fstab2
regexp: '(\S+\s+\S*/tmp/mounts/{{ item.0
}}\S*\s+\S+\s+)(\S+)(\s+\S+\s+\S+)'
line: '\1\2,{{ item.1 }}\3'
backrefs: yes
backup: yes
when: "'{{ item.1 }}' not in (ansible_mounts|selectattr('mount',
'equalto', '/tmp/mounts/' ~ item.0)).0.options"
loop: "{{ mount_point|product(mount_flags)|list }}"
# NOTE: item.0 are the 'mount_point' entries, and item.1 are the
'mount_flags' entries.
Now I know it *can* be done, but *should* it be done...or will this end up
being a playbook that *only* I can support at 3AM... :-/
Dan
On Tuesday, January 18, 2022 at 6:20:04 AM UTC-6 dick....@geant.org wrote:
> You don't have to split the opts by comma, just checking if 'nodev' is
> enough.
> If it isn't there, you can then append it:
>
>
> - name: "Add nodev to /tmp/mounts/mount*"
> mount:
> path: '/tmp/mounts/{{ item }}'
> src: '/tmp/{{ item }}'
> fstype: xfs
> opts: '{{ (ansible_mounts|selectattr('mount', 'equalto',
> '/tmp/mounts/' ~ item)).0.options }},nodev"
>
> state: present
> passno: '0'
> dump: '0'
> backup: yes
> with_items:
> - mount01
> - mount02
> when: "'nodev' not in (ansible_mounts|selectattr('mount', 'equalto',
> '/tmp/mounts/' ~ item)).0.options"
>
> The only thing with this approach is that it explicitly sets all the flags
> that are reported by ansible_mounts - but this might be a good idea anyway.
>
> Dick
>
>
> On Tue, 18 Jan 2022 at 03:47, Dan Linder <d...@linder.org> wrote:
>
>> I've got a variety of mounts that I want to ensure specific flags are set
>> on each. For other reasons, the mounts don't have the same flags.
>>
>> I mistakenly thought the 'mount' module would ensure each had the flag,
>> but instead it set the flags of the mount to ONLY the 'opts' parameter.
>>
>> For instance, I have a test system with these two mounts:
>> /tmp/mount01 /tmp/mounts/mount01 xfs defaults,*noatime,nodev *0 0
>> /tmp/mount02 /tmp/mounts/mount02 xfs defaults,*relatime,noexec *0 0
>>
>> Note the changes in the mount options.
>>
>> I setup this play in a playbook:
>> - name: "Add nodev to /tmp/mounts/mount*"
>> mount:
>> path: '/tmp/mounts/{{ item }}'
>> src: '/tmp/{{ item }}'
>> fstype: xfs
>> opts: 'nodev'
>> state: present
>> passno: '0'
>> dump: '0'
>> backup: yes
>> with_items:
>> - mount01
>> - mount02
>>
>> But ended up getting the mounts (in /etc/fstab) like this:
>> /tmp/mount01 /tmp/mounts/mount01 xfs *nodev* 0 0
>> /tmp/mount02 /tmp/mounts/mount02 xfs *nodev* 0 0
>>
>> Since I'm 'gathering_facts', I thought I could use the 'ansible_mounts'
>> list, but the options are just a simple string:
>> {
>> ...
>> "fstype": "xfs",
>> ...
>> "mount": "/tmp/mounts/mount01",
>> "options": "rw,seclabel,nodev,noatime,attr2,inode64,noquota",
>> ...
>> }
>>
>> In a much more complex playbook, I have pulled out the individual
>> 'options' parameters and could append the new 'opts' parameters to each -
>> but that ends up doing a simple appending which ends up in the /etc/fstab
>> file so each run adds another value.
>>
>> *My question: *Is there a simpler way that I'm overlooking to ensure
>> that 'nodev' - or any single parameter is provided to 'opts' - is in each
>> mount without having to define the entier (and potentially unique) 'opts'
>> string for each mount?
>>
>> If the 'options' within the 'gather_facts' was also a list, then adding
>> the 'nodev' element wouldn't lead to the duplication issue... If the
>> 'mount' 'opts' parameter took a list, then it would be possible to convert
>> the CSV string to a list, then append the single 'opt' to the list.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ansible-proje...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/f65e34d2-2b8c-4bc8-bc34-6f3eddf44be1n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/f65e34d2-2b8c-4bc8-bc34-6f3eddf44be1n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Dick Visser
> Trust & Identity Service Operations Manager
> GÉANT
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/6cbcec18-6482-449e-bbbb-d1f67d852fa3n%40googlegroups.com.
