firewalld 0.7.2

Just one little bit about 0.7.2:

since this release masquerading is off by default for IPv6. To get back to the old behaviour you have to manually insert one rich rule in the external zone:

firewall-cmd --permanent --zone=external --add-rich-rule="rule family=ipv6 masquerade"

…that actually cost me about one day to realize that this was the root cause of my network troubles after upgrading my firewall from 15.0 to 15.1…

LeapUP 15.0 -> 15.1

So the other day I got an advanced discontinuation warning for openSUSE Leap 15.0 which reaches EOL on November 30, and today I took that Leap (fun intended) and used my trusted little leapup script to upgrade my systems to 15.1… and what can I say, so far I’ve done my laptop and my desktop which could have been a bit tricky because there’s so much stuff installed, and one of my cloud servers – and except for some little bits of LVM juggling because / ran full on my desktop all went without a hitch.

That’s pretty much all I have to report about it.

Edit: Finished the second cloud server, no problems at all.

Finale grande: all systems upgraded without major problems. That’s how that is supposed to work.

Mozilla Thunderbird 68.0

<tl;dr>
no thanks
</tl;dr>

Long version:

I just got updated to Thunderbird 68.0 on my linux desktop systems.

Started it, and found that ALL add-ons except two had been disabled or removed, and the two that were left did not do anything anymore.

For example, lightning was still there but there was no way to actually open your calendar.

Good thing I had a way to roll back to 60.8. That one works the way I need it to.

Microsoft wants to push exFAT-Support directly into the Linux kernel

Here’s a little piece on one of microsoft’s many blogs…

I kind of think that this might actually be a really huge bit of news.

Why? My biggest two reasons are:

  1. Smartphone manufacturers making android phones won’t have to license the exFAT patent anymore to be able to support sd card storage on their devices.
  2. Microsoft used to use the patent on exFAT for years as a “weapon” to fight Linux. Now they themself want linux to support exFAT.

my trusted leapup script, 42.3 -> 15.0… ouch.

…not happy.

So I’ve used my trusted little leapup script for an upgrade from 42.3 to 15.0, and in three out of three cases it was not fun…

On my two cloud servers all I had was some glitchiness with the firewall, and I have to figure out how to rebuilt the latest version ot the xtables addons on Leap 15.

On my desktop I guess I’ve screwed up during the first stage of the upgrade, and missed one dependency quirk or someting, but … that left me dead in the water on that machine. Actually had to do a standard upgrade from DVD on that one.

I am not looking forward to upgrading the main firewall. Guess that’ll wait until my laptop comes back from repairs so I can use that one as a second testbed.

 

That being said, I found a few typos in my leapup script that bit me in the *** too.

Managing windows hosts with ansible

Lately I’ve been experimenting with ansible a lot.

Dealing with linux hosts is straightforward enough, and you’ll be able to find all sorts of information with google, but ansible can also deal with windows hosts, and that’s where it gets a bit more interesting.

To be able to manage a windows host with ansible, you have to:

  • create a user account on the machine (or in the windows domain) who has to be a member of the administrators group
  • follow the instructions in the ansible documentation about how to enable winrm
  • make sure you use the right ansible modules, if there are special modules for windows for any given purpose they will start with win_, for example instead of copy: for a windows host you’d use win_copy. Some modules simply do not exist as a win_ version, but the generic unix version does not work on windows, for example the telegram notification module, but that you can safely delegate_to: localhost when you want to use it (unless your management host does not have internet access).
  • set up a group in your inventory for your windows hosts, and add the variables for winrm access as group_vars for that group

Here’s an example for a simple playbook that installs all the latest updates, and reboots the target host if necessary:

---
- name: Install all windows updates
  hosts: all

  tasks:

  - name: install all updates
    win_updates:
      category_names:
        - SecurityUpdates
        - CriticalUpdates
        - UpdateRollups
      state: installed
    register: update_result
    notify:
      - telegram-notify
      - reboot-if-required

  handlers:

  - name: telegram-notify
    telegram:
      msg: "{{ ansible_fqdn }}: updates installed."
      token: "{{ eregion_home_telegram_token }}"
      chat_id: "{{ eregion_home_telegram_chat_id }}"
    delegate_to: localhost

  - name: reboot-if-required
    win_reboot:
    when: update_result.reboot_required and not eregion_home_has_dualboot

You’ll notice that the handler: that reboots the target has a when: condition that uses a variable I haven’t mentioned yet. It’s easy enough: two of the windows hosts I am managing have dual boot setups, by default they reboot to linux. I’m dealing with that by creating TWO host entries in my inventory, the regular one, and one with a different name, and two host_vars:

lemmy@kumiko:~/.ansible/inventory> tail -6 51-hosts
[windows]
kumiko-win
kirika-win
yuzuyu.eregion.home

and

lemmy@kumiko:~/.ansible/inventory> cat host_vars/kumiko-win.yml 
---
ansible_host: kumiko.eregion.home

This works with ansible on the command line and with ansible tower.

Captive portals are even worse than you thought.

I just came across this article about captive portals (these annoying websites that force you to a “accept TOS” page on public wifis) that we all hate so much.

I can only agree with what’s said in there, to 200%, but it’s even worse than that: A captive portal is a real danger to the security of your mobile device.

An attacker could easily setup a microcomputer for 15$ to run as access point, and send out the SSID of a well known public WiFi, and then redirect every client to a version of that WIFI’s captive page that has malicious things built it. It could trick you into giving away your credit card information, social security number, or any other valuable information, or maybe even worse, install backdoors on your device.

Say NO to captive portals.