Scenario:

Use specific variables, depending on the environment a playbook is run in. In this example either a low load or high load environment

Playbook:

- hosts:
    - localhost
  gather_facts: no

  vars:
    - lowload_app_java_opts: "-Xms512m -Xmx2G"
    - highload_app_java_opts: "-Xms4G -Xmx8G"
    - services:
        - lowload_app
        - highload_app

  tasks:
    - debug:
       msg: "fixed_var: {{ lookup('vars', service_name + '_java_opts') }}"
      loop: "{{ services }}"
      loop_control:
        loop_var: service_name

Output (truncated):

$ ansible-playbook -v programatic_variable_lookup.yml
PLAY [localhost] *******************************************************************

TASK [debug] ***********************************************************************
ok: [localhost] => (item=lowload_app) => {
    "msg": "fixed_var: -Xms512m -Xmx2G"
}
ok: [localhost] => (item=highload_app) => {
    "msg": "fixed_var: -Xms 4G -Xmx8G"
}

PLAY RECAP *************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0

We had a problem on a storage server. One user was not able to authenticate with the Samba service using his Active Directory credentials. Furthermore I couldn’t find his user via getent passwd AD\\username. After checking several LDAP/Kerberos/PAM configuration files, I had the glorious idea to also check the logs of winbind.

[2019/01/29 14:05:16.726252,  1, pid=4467, effective(0, 0), real(0, 0)]   Fatal Error: UID range full!! (max: 60000)
[2019/01/29 14:05:16.726299,  1, pid=4467, effective(0, 0), real(0, 0)]   Error allocating a new UID
[2019/01/29 14:05:16.726339,  1, pid=4467, effective(0, 0), real(0, 0)]   no backend defined for idmap config BUILTIN
[2019/01/29 14:05:16.726903,  1, pid=4467, effective(0, 0), real(0, 0)]   Fatal Error: GID range full!! (max: 60000)
[2019/01/29 14:05:16.726948,  1, pid=4467, effective(0, 0), real(0, 0)]   Error allocating a new GID

Huh, interesting. This wasn’t a heavily used server. Neither users nor groups were even in the proximity of 60000. Accordingly increasing the idmap uid/idmap gid did not help at all.
Several hours later I found the solution in the arstechnica forum:

Long story short, stop winbind, delete winbindd_cache.tdb & winbindd_idmap.tdb from /var/cache/samba, then restart winbind. Mappings now happen right. So I can log in with domain accounts and access shares.

The provided path /var/cache/samba did not fit for the Red Hat Enterprise Linux running on this server. But finding out that winbindd_cache.tdb and winbindd_idmap.tdb are located in /var/lib/samba was no big deal after nearly 60 minutes of unnecessary debugging.

I recently read about Microsoft forcing users to update Skype Classic (aka version 7) to the new version 8 by denying an application start after updating Skype Classic to a newer version.

I’m rarely using Skype at home, but I know a lot of people who do. Therefore I’m already preparing for the questions of how to circumvent this forced update. As already stated on bleepingcomputer, the only way of staying on Skype Classic is to downgrade to version 7.36.0.101. For convenience I’m providing this version for donwload here:

• Original MSI installer
  [SHA256: 91d5a8eee02745335f753e62b8914c3cd30df4539fc018a2818dcf7dfc8dfd6f]
• Original MSI installer in a zip file(For people whose security policies or virus scanners do not allow MSI file downloads)
  [SHA256: d84b52f4ef5aa02b07a8c745624e70990737a2e2dc94dfec2cbda0579338db60]

Bleepingcomputer also provided the original MD5Sum “0ec4d8991728ded1107598c789f0ec89” of the Installer. I’d recommend checking the MSI files you download here against that sum, just to be safe.

Update April 2020: J. Reis rightfully mentioned in the comments this is not a good way. OpenWRT recommends flashing a sysupgrade.

There seems to be some indication that this may be a terrible idea and isn’t actually supported by OpenWRT in any official way (which may account for the lack of any simple GUI way of performing this function): https://forum.openwrt.org/t/okpg-upgrade-safeguards/30326

https://forum.openwrt.org/t/opkg-upgrade-vs-flashing-sysupgrade/58906 https://forum.openwrt.org/t/sysupgrade-instead-of-opkg-upgrade/32897/4

Original Post

I’m using OpenWRT on my Linksys WRT3200ACM. As the integrated package manager opkg does not have a pendant to apt-get dist-upgrade, this is the command I regularly execute, to upgrade the system:

opkg update && opkg list-upgradable| awk '{print $1}'| tr '\n' ' '| xargs -r opkg upgrade

I recommend running this command in a session detached from SSH. This way you’re safe in case your machine or the router get network problems. I’ve ran into that problem once which cost me a couple of hours for debuggin. Therefor I run the command in a detached tmux session:

tmux new -d "opkg update && opkg list-upgradable| awk '{print $1}'| tr '\n' ' '| xargs -r opkg upgrade"

If you are brave, you can automate this via cron. I prefer doing supervised updates regularly, as my router is a rather critical part of my infrastructure.

Did you ever need a different Python version on an Ansible Node? Or a different Python module version? I did.

The Ansible modules openssl_certificate and openssl_csr require pyOpenSSL >= 0.15. This is not the case for Red Hat Enterprise Linux 6 servers. The Python installation I wanted to use with Ansible needed to have an enabled Python SCL and an activated Python Virtual Environment (because I didn’t want to fiddle with the original SCL modules) before running its commands.

Therefore I created the small shell script python36-starter.sh:

#!/bin/bash
. /opt/rh/rh-python36/enable
. /opt/python-venv/bin/activate
exec python "$@"

It’s pretty much self-explanatory. By sourcing the enable and activate files of SCL and Virtual Environment, the correct pathes for Python binaries and libraries are set. Then the “new” Python binary is executed with all arguments the script was called with.

By adding the ansible_python_interpreter configuration parameter to the according host in the inventory this script will be used by Ansible in future runs.

[webservers]
prodweb
simuweb
testweb
webcert ansible_python_interpreter=/usr/local/bin/python36-starter.sh
xweb

This small hack could be extended even further. You could export environment variables in it or do some logging or auditing stuff. But keep in mind this is a dirty hack. Do not give up the freedom and clarity Ansible provides by overextending “quick and dirty” hacks.