Hacker's ramblings

For ages spammers' tactic has been to use either free trial of a service or payment via "liberated" credit card. As public cloud service providers want to lure in new customers, there is a habit of offering non-paid services for a period of time. All major providers like AWS, Azure and Google Cloud Platform have such free-of-charge use available.

Also smaller companies have such offering. Smaller companies (are still quite big, but not as big as biggest ones) would include Hetzner and OVHcloud. Both have number of data centers around the Europe and for any postmaster, are a royal pain in the ass. You can get a really cheap VM on either and start spewing spam email into unsuspecting SMTP-servers, like the one I maintain.

This type of free-spam-for-all isn't sustainable, or hasn't been for years, but these companies still allow it to happen. In 2021 Hetzner made a change for better. Lot wasn't communicated, however, this information was published to its customers:

Microsoft Blacklist

Microsoft maintains their own internal blacklists, which are used to reject emails coming from specific IP addresses.

Note: Entire info is available @ Hetzner website.

As a customer of Hetzner having an operational VM, I bumped into a new undocumented restriction applied to new accounts. On my own box, everything still works as usual. Has been for years. To my surprise, outgoing TCP/25 on a new account having a new VM is blocked. What!? Investigating this, led me to Hetzner customer support site, as it has following options for support request:

There is a drop-list with different types of problems having a specific category of Sending mails not possible. Apparently somebody designed the support pipeline for that particular need.

Lack of official documentation made me look in The Net. There I found a confirmation of this policy change. In June 2021 Bjørn Erling Fløtten of Norway wrote in his blog post Ditching Windows and AWS, diving into Linux and Hetzner following story:

Step 8: Setting up an email server

...

(This reminds me of the good old days when a mail server by default usually would be an open relay. Now you definitely get a more secure basic install)

Now I could actually also telnet to port 25 from my Amazon instance, and the connection appeared in the Postfix log. I have no clue why it did not work on the first attempt.

Time to ask Hetzner to open port 25 outbound (SMTP port).

(There is no mentioning of port 25 blocking anywhere on Hetzner's pages. But it is of course natural to assume that port 25 is blocked, even though the firewall administration page of Hetzner's Cloud Console says "All outbound traffic is allowed. Add a rule to restrict outbound traffic.").

So I decided to open a Support ticket, which suggest:
"Server issue"
and
"Server issue: Sending mails not possible"
Choosing the latter gives this:
"Outgoing traffic to ports 25 and 465 are blocked by default on all Cloud Servers.
A request for unblocking these ports and enabling the send mail option is only possible after the first paid invoice."

Fair enough, some thrust needs to be established.

Invoice information says:
"Invoice information
You currently receive 1 invoice a month.
The invoice will be created on the following day:
...th of the month"

...

Bjørn: Hint! Get a free-of-charge TLS-certificate somewhere. Most browsers refuse to enter your site. Thanks, though, for sharing your experience. Now I know to first wait for the invoice and then request for the ports to be opened.

Hetzner: Hint! Would it be smart to document all of this somewhere? Thanks for this change in your policy, though. Anybody needing SMTP will eventually get access. Deactivating option to spam at will makes life of criminals looking for the-easy-way look for other alternatives. This new policy leaves plenty of details about perpetrator's identity for police to investigate.

Update 19th Sep 2022:
Hetzners rules are both of these need to be true:

• First invoice must be paid
• Account must be at least month old

By paying, your SMTP-ports won't open. They open only after bit of a wait.

Few years back I wrote about running Linux on a MacBook Pro. An year ago, the OpenSuse failed to boot on the Mac. Little bit of debugging, I realized the problem isn't in the hardware. That particular kernel update simply didn't work on that particular hardware anymore. Totally fair, who would be stupid enough to attempt using 8 years old laptop. Well, I do.

There aren't that many distros I use and I always wanted to see Fedora Workstation. It booted from USB and also, unlike OpenSuse Leap, it also booted installed. So, ever since I've been running a Fedora Workstation on encrypted root drive.

One glitch, though. It didn't always sleep wake. Quite easily, I found stories of a MBP not sleeping. Here's one: Macbook Pro doesn't suspend properly. Unlike that 2015 model, this 2013 puppy slept ok, but had such deep state, it had major trouble regaining consciousness. Pressing the power for 10 seconds obviously recycled power, but it always felt too much of a cannon for simple task.

Checking what ACPI has at /proc/acpi/wakeup:

Device  S-state   Status   Sysfs node
P0P2      S3    *enabled   pci:0000:00:01.0
PEG1      S3    *disabled
EC        S4    *disabled  platform:PNP0C09:00
GMUX      S3    *disabled  pnp:00:03
HDEF      S3    *disabled  pci:0000:00:1b.0
RP03      S3    *enabled   pci:0000:00:1c.2
ARPT      S4    *disabled  pci:0000:02:00.0
RP04      S3    *enabled   pci:0000:00:1c.3
RP05      S3    *enabled   pci:0000:00:1c.4
XHC1      S3    *enabled   pci:0000:00:14.0
ADP1      S4    *disabled  platform:ACPI0003:00
LID0      S4    *enabled   platform:PNP0C0D:00

For those had-to-sleep -cases, disabling XHC1 and LID0 did help, but made wakeup troublesome. While troubleshooting my issue, I did try if disabling XHC1 and/or LID0 would a difference. It didn't.

Also, I found it very difficult to find any detailed information on what those registered ACPI wakeup -sources translate into. Lid is kinda obvious, but rest remain relatively unknown.

While reading System Sleep States from Intel, a thought occurred to me. Let's make this one hibernate to see if that would work. Sleep semi-worked, but I wanted to see if hibernate was equally unreliable.

Going for systemctl hibernate didn't quite go as well as I expected. It simply resulted in an error of: Failed to hibernate system via logind: Not enough swap space for hibernation

With free, the point was made obvious:

               total        used        free      shared  buff/cache   available
Mem:         8038896     1632760     2424492     1149792     3981644     4994500
Swap:        8038396           0     8038396

For those not aware: Modern Linux systems don't have swap anymore. They have zram instead. If you're really interested, go study zram: Compressed RAM-based block devices.

To verify the previous, running zramctl displayed prettyy much the above information in form of:

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       7.7G   4K   80B   12K       8 [SWAP]

I finally gave up on that by bumping into article Supporting hibernation in Workstation ed., draft 3. It states following:

The Fedora Workstation working group recognizes hibernation can be useful, but due to impediments it's currently not practical to support it.

Ok ok ok. Got the point, no hibernate.

Looking into sleep wake issue more, I bumped into this thread Ubuntu Processor Power State Management. There a merited user Toz suggested following:

It may be a bit of a stretch, but can you give the following kernel parameters a try:

• acpi=strict
• noapic

I had attempted lots of options, that didn't sound that radical. Finding the active kernel file /boot/vmlinuz-5.18.18-200.fc36.x86_64, then adding mentioned kernel arguments to GRUB2 with: grubby --args=acpi=strict --args=noapic --update-kernel=vmlinuz-5.18.18-200.fc36.x86_64

... aaand a reboot!

To my surprise, it improved the situation. Closing the lid and opening it now works robust. However, that does not solve the problem where battery is nearly running out and I plug the Magsafe. Any power input to the system taints sleep and its back to deep freeze. I'm happy about the improvement, tough.

This is definitely a far fetch, but still: If you have an idea how to fix Linux sleep wake on an ancient Apple-hardware, drop me a comment. I'll be sure to test it out.