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.

Seamless openSUSE Leap upgrades made easy

Hi everyone,

 

I’ve started to put my trusted approach to seamless openSUSE upgrades into an easy to use shell script.

The script operates under a few assumptions (yes I know, assume makes an ass out of you and me), but what can you do, except calling them prerequisites:

  • Your system has all the latest updates applied according to your current repository setup (run “zypper patch; zypper dup” until there is nothing left to install)
  • All enabled repositories have priorities set that make it crystal clear which of them are preferred over which in case a package appears in more than one repo
  • All enabled repositories also exist for the target version, and use a repository URL that has that version number in it, and where the version number is the only difference between versions (this should usually be true for repositories from OBS and/or packman, buy YMMV)

If all this is true, running the script will create a backup of your current repository structure under /etc/zypp/repos.d_(current_version), and a repo setup for the target version under /etc/zypp/repos.d_(target_version), and then link the new structure to /etc/zypp/repos.d, and after that it will clean zyppers cache, refresh all repositories, and tell you the commands to execute to actually run the upgrade.

You might want to do those commands inside a screen session. You have been warned.

This script is provided with no warranty at all. Use it at your own risk. If you break things you get to keep the pieces.

If by any chance your root filesystem is on either LVM or btrfs, do a snapshot before you start upgrading your system.

Download the script here: leapup.tar.xz

So far I have used this script on two desktop systems which each use 20++ different repositories from OBS and packman, and no problems (aside from a few glitches in 42.3 that are connected to the nvidia drivers, but not to this upgrade process).

 

Update: in the last 4 days I updated five different machines using my script: my desktop computer which runs with 23 different repositories from OBS, my laptop and my work laptop which both run with 25 repos, my cloud host which runs with 10 repositories and my internal server/firewall which also runs with 10 repositories… no problems so far.

Update: There is now a RPM package for openSUSE Leap 42.3 and 15.0 here: https://software.opensuse.org/package/leapup?search_term=leapup