The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,231 other followers

Archive for the ‘*nix’ Category

TUMBLEWEED Ordering cycle at boot with nss-lookup: named fails to start initially; workaround: manually `rcnamed start`

Posted by jpluimers on 2021/01/15

I have seen this on one Raspberry Pi 3 system: named failing to start during a normal reboot.

The solution is to manually rcnamed start as root after boot.

From [Wayback] TUMBLEWEED Ordering cycle at boot with nss-lookup, the rcnamed status is the same as on my system, but no solution in that thread:

# systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
     Active: inactive (dead) Jul 02 08:13:40 hpprol2 systemd[1]: nss-lookup.target: Found ordering cycle on named.service/start
Jul 02 08:13:40 hpprol2 systemd[1]: nss-lookup.target: Found dependency on time-sync.target/start
Jul 02 08:13:40 hpprol2 systemd[1]: nss-lookup.target: Found dependency on ntpd.service/start
Jul 02 08:13:40 hpprol2 systemd[1]: nss-lookup.target: Found dependency on nss-lookup.target/start
Jul 02 08:13:40 hpprol2 systemd[1]: nss-lookup.target: Job named.service/start deleted to break ordering cycle starting with nss-lookup.target/start

Apparently, sometimes there is a service startup dependency loop, and named becomes the victim of it, effectively rendering DNS inoperable.

My system was running this version of Tumbleweed:

statler:~ # cat /etc/SUSE-brand /etc/os-release 
openSUSE
VERSION = tumbleweed
NAME="openSUSE Tumbleweed"
# VERSION="20200825"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20200825"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20200825"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
LOGO="distributor-logo"

On an identical system, the boot just worked fine, so it might be timing related.

waldorf:~ # cat /etc/SUSE-brand /etc/os-release 
openSUSE
VERSION = tumbleweed
NAME="openSUSE Tumbleweed"
# VERSION="20200825"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20200825"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20200825"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
LOGO="distributor-logo"

–jeroen

Posted in Linux, openSuSE, Power User, SuSE Linux | Leave a Comment »

TODO: if weerslag hasn’t supported https yet, dig deeper into ProxyPass / ProxyPassReverse

Posted by jpluimers on 2021/01/12

I’ve this page for my brother: https://martijn.pluimers.com/agenda-month-weather.html.

It serves his agenda plus a few weather widgets.

The weerslag widget fails to load as it’s in an iframe pointing to http but the page is https. That’s not allowed as shown in this nice table at [WayBackssl – Insecure content in iframe on secure page – Stack Overflow by amol-ghotankar and richard:

page  - iframe - status
----- - -----  - -----------
http  - http   - allowed
http  - https  - allowed
https - http   - not allowed
https - https  - allowed

So I put it behind a simple Apache reverse proxy: https://www.pluimers.com/maps.weerslag.nl/GratisRadar/1201/864/verwacht?zoom=10:

<Location /maps.weerslag.nl>
ProxyPass http://maps.weerslag.nl
ProxyPassReverse http://maps.weerslag.nl
Require all granted
</Location>

If they still haven’t fixed their https access, I need to dig deeper into this.

When writing this [Arhive.ishttps://maps.weerslag.nl/GratisRadar/1201/864/verwacht?zoom=10 gave a 404 and http://maps.weerslag.nl/GratisRadar/1201/864/verwacht?zoom=10 misbehaved behind the proxy:

–jeroen

Posted in *nix, Apache2, Development, Power User, Web Development | Leave a Comment »

Opensuse Community Account Migration

Posted by jpluimers on 2021/01/11

Apparently, during my 15 month rectum cancer fight, I missed the one month window of migrating my opensuse account (because of the sale of opensuse from Microfocus to a German investment company named EQT Partners).

I got the email on may 1st (right before my first surgery) and since I only just am recovering from the last surgery, discovered [Wayback] Community Account Migration:

The Community Accounts (aka. Bugzilla Accounts) will migration to the SUSE datacenter in Nuremberg

SUSE is the largest independent open source company.
We are finalizing this independence also on the technical level.
The Community Accounts (a.k.a. Bugzilla Accounts) were moved back to SUSE to a new system in our Nuremberg data center.

All accounts have been migrated. Except for the password.
To access your migrated account a migration tool was offered until June 18th
The migration is no longer possible.
To regain access to your account you have to request a password reset.
This requires that the account has your correct email address registered.
If this is not the case you will have to create a new account.

It looks like the account migration uses Okta (identity management) – Wikipedia as authentication service (quite odd for a German company to use a USA based company for authentication: hellp GDPR!), using mail servers having hostnames not ending in opensuse.org, but like o#.mailrelay.okta.com.

Hopefully identify emails do get through: they are now trying to get past my grey-list filters.

Edit:

The okta mail servers didn’t get through the grey-list, so I forced them to the secondary mail servers where they did get through.

It indicated migration is not possible any more and I should seek help:

At this time your password can only be reset by an administrator. To send them a request, go to your Sign-in Help page. Then click the Request help link.

So I did:

Hi,

Due to my 15 months fight with rectumcancer and the “SUSE Account Changes – Coming soon!” last May not indicating any deadline for the migration, I missed the one month account migration window (2020-05-18 to 2020-06-18) mentioned at https://idp-portal-info.suse.com/

Can you please re-activate the account jeroen.suffix@example.com and re-bind the forums.opensuse.org username accountname for me and send me a password reset email on that above email address?

Thanks,

–jeroen

Edit 20210112:

I got an account activation email, added password/question/mobile-phone-number, then got redirected to https://myaccount.suse.com/app/UserHome, then the “Forums” link allowed me to enter a forums alias the same as my old alias. So it looks it sort of works now: my old jpluimers posts have not been linked to my new account.

Some reading for when I have more energy:

I just checked and the email about migration did not indicate any deadline apart from that password reset links were valid for 90 days, a lot longer than one month window.

–jeroen

Posted in *nix, Linux, openSuSE, Power User, SuSE Linux | Leave a Comment »

🔎Julia Evans🔍 on Twitter: “ssh tips… “

Posted by jpluimers on 2021/01/08

Great work by [WayBack]  🔎Julia Evans🔍 on Twitter: “ssh tips… “

[WayBackssh tips JPG

Via:

Some more tips:

Read the rest of this entry »

Posted in *nix, *nix-tools, Communications Development, Development, Internet protocol suite, Power User, SSH, ssh/sshd | Leave a Comment »

Binding #Uptimerobot monitoring to your own subdomain: embarcaderomonitoring.wiert.me

Posted by jpluimers on 2021/01/01

Below a few screenshots on how to bind your own subdomain to a set of uptimerobot monitors.

This case is about [Archive.isembarcaderomonitoring.wiert.me, which I setup because of the not so well way that Embarcadero maintained their web facing infrastructure in the past.

The steps for that are really simple, assuming you already have an uptimerobot account and some monitor set-up. If you don’t: check out the first video (thanks onewebstreet!) linked below the fold, as it is a step-by-step introduction.

Steps for your own subdomain

If you like video more than a list of steps, check out the second video (thanks Kyle!) below the fold.

  1. Ensure you have a DNS CNAME record that points your subdomain (in my case embarcaderomonitoring.wiert.me) to stats.uptimerobot.com:

    Note that [Archive.is] stats.uptimerobot.com by itself will not display any dashboard, as it requires a CNAME to be involved that is registered in the Uptime robot Custom Domain list.

  2. Login to Uptime robot, which brings you to uptimerobot.com/dashboard#mainDashboard
  3. Click on settings, which brings you to uptimerobot.com/dashboard#mySettings
  4. Observe the “Disable RSS” (or “Enable RSS” if you have not yet enabled it) and the “this link” (which in my case points to this RSS feed [WayBack])
  5. Clicking on “show them” will get you something like this:
  6. Clicking on the pencil icon then will get you where you can set the “Custom Domain”, which notes

    Custom Domain

    (make sure you create a CNAME DNS record for your domain to stats.uptimerobot.com. And, it can take up to 30 mins for the custom domain to be activated.)

  7. Wait a while and check your CNAME for a valid Uptime robot status dashboard.

–jeroen

Read the rest of this entry »

Posted in *nix, LifeHacker, Monitoring, Power User, Uptimerobot | Leave a Comment »

 
%d bloggers like this: