Notice: LineageOS build repository discontinued.

Awhile back, I mentioned that my bandwidth was being consumed by a few bad actors out there who are scraping the entire LineageOS build repository.

This is still happening. It’s been especially bad over the past week.

I’ve been null-routing entire networks in an attempt to keep the service running while preventing jerks from hoovering the entire repo. It’s turned into a game of whack-a-mole, and honestly, providing this service isn’t worth the cycles I’m burning keeping things running for an indifferent “community”.

As of today, the LineageOS build service has been discontinued.

My build script is at https://www.disavowed.jp/lineageos/build-lineage.sh for those who need security updates for their devices.

I’m very sorry to have to do this. I’m especially sorry towards the eight people who have donated over the past few years to support this service. This is why humans can’t have nice things.

Posted in LineageOS | 7 Comments

LineageOS sustaining build repository moved to lineageos.rezrov.net

Multiple people have pinged me regarding lineageos.disavowed.jp having issues.

lineageos.disavowed.jp was deprecated several months ago in favor of lineageos.rezrov.net and the SSL certificate for the old domain finally expired.

I’ve therefore removed the HTTPS redirect to lineageos.rezrov.net with a simple HTTP redirect (because, natch, there won’t be a valid SSL cert for the redirect anymore).

Again: lineageos.disavowed.jp is dead. Use lineageos.rezrov.net.

Thank you.

Posted in LineageOS | Leave a comment

A sane Octoprint (octopi) USB camera daemon

Octoprint is neat. However, the USB/webcamera support is a bit obtuse — especially when you throw haproxy into the mix.

The Octoprint documentation recommends using mjpg-streamer as a standalone daemon to convert a v4l video stream into a HTTP stream … and use haproxy to selectively redirect traffic to that stream when an arbitrary value prepends the HTTP URI.

There are a few issues:

  • The recommended haproxy.cfg isn’t compatible with current versions of haproxy,
  • Octoprint appends a seemingly-random session ID to the camera URI, which confuses the hell out of mjpg-streamer,
  • mjpg-streamer doesn’t appear to handle multiple simultaneous streams, resulting in the infuriating “403: Forbidden! frame already sent” error,
  • mjpg-streamer itself is complete overkill here.

Wanting this to work, I looked around for a simpler scheme. I came across Igor Maculan’s “Simple Python Motion Jpeg” daemon (https://gist.github.com/n3wtron/4624820), which looked promising.

I spent a few hours this morning porting it to python 3.x, fixing a few bugs, and adding command-line tunables. It works, and it works well. It is available on GitHub at https://github.com/christopherkobayashi/octoprint-stuff/blob/main/webcam.py

Below is a working haproxy.cfg that handles SSL:

global
	maxconn		20000
	log		127.0.0.1 local0
	user		haproxy
	chroot		/usr/share/haproxy
	pidfile		/run/haproxy.pid
	daemon

defaults 
	timeout		connect 5s
	timeout		client 1m
	timeout		server 1m

frontend public_ssl
	bind		:::443 v4v6 ssl crt /etc/letsencrypt/live/both.pem
	use_backend	webcam if { path_beg /webcam/ }
	default_backend	octoprint

backend octoprint
	mode		http
	http-request	replace-uri '^([^\ :]*)\ /(.*)' '\1 /\2'
	option		forwardfor
	server		octoprint1 127.0.0.1:5000

backend webcam
	mode		http
	http-request	replace-uri '^([^\ :]*)\/webcam/(.*)$' '\1/\2'
        server webcam	127.0.0.1:8080

The Octoprint web camera URL should be “https://${SERVER_NAME}/webcam/${SOMETHING}.mjpg”. ${SOMETHING}.mjpg can be anything, actually … webcam.py will respond to any request with a MJPEG stream.

I hope this saves time for others banging their heads against Octoprint’s … interesting camera support scheme.

Leave a comment

LineageOS builds for Asus Zenfone 2 (1080p) (Z00A) … and site updates

While cleaning up my work room a few months ago, I found an old Asus Zenfone 2 tucked away in a desk drawer.

The Zenfone 2 is a neat idea executed poorly. It’s dual-SIM (which is why I bought it — it was my China phone, with a China Mobile and a Hong Kong SIM), solidly constructed, with a really good screen. However, one of the SIM slots is 2G-only, it’s using an Intel Atom (x86) processor, and the battery is infamous for randomly dying.

I hooked it up to a USB charger, figuring I’d give the battery a good solid regenerating charge to see if it was worth keeping, and promptly forgot about it. I discovered it again a few days ago (still charging) and tried it out.

Much to my surprise, it booted.

It was supported by LineageOS 14.1. I did a quick build, flashed it onto the device … and it still worked. I’ve added it to the weekly build rooster.

Stock TWRP 3.3.1 (as sourced from twrp.me) works fine. The MM bootloader is probably required; I’ve put a copy of the upgrader in the z00a directory.

Magisk will not work. There’s something odd going on with the bootloader’s kernel image integrity check — after Magisk injects itself into the image, the bootloader will refuse to load it, choosing instead to enter recovery. The fix there is to use LineageOS’ addonsu package. The binary on the official LineageOS site will not work, as one of the ABIs apparently changed in the past few years. I’m now generating the addonsu (and addonsu-remove) package along with the regular build for each platform.

On a different note: I’ve moved the repository from lineageos.disavowed.jp to lineageos.rezrov.net. These builds are apparently a bit popular; I’m seeing people grab these from all over the place (referred from YouTube tutorials, Russian and Japanese forums, in addition to the usual XDA traffic). That makes me happy, but …

… unfortunately, only six people have donated to the webhosting fund. I’ve had to bring the repository in-house to cut costs. I’m really disappointed in the gimme-gimme-gimme mindset displayed by the vast majority of LineageOS users.

I’ll keep the builds available as long as I can, but do not be surprised if the site is one day replaced with a static “so long and thanks for all the fish” page to keep my ISP from throttling my bandwidth. At that point I’ll post my build script and redirect software-lineageos@disavowed.jp to /dev/null.

Anyway … enjoy the Z00A builds.

Posted in LineageOS | 4 Comments

netatalk-classic-20200921 released

I’ve been repairing old 68030- and 68040-class Macintoshes for the past few years. It’s a fun hobby, and allows me to reconnect to an Apple era that was long-gone by the time I joined Apple.

At this point, we have a SE/30, a Classic II, a IIsi, an LC III, a Centris 650, a Quadra 700, and a Quadra 950. All are networked, either through Asanté PhoneNet-to-Ethernet bridges or direct Ethernet.

For the last quarter-century, Netatalk has been the go-to solution for file/printer sharing between UNIX and AppleTalk. Version 2.2.6 was the last release that supported classic DDP AppleTalk (as opposed to AppleTalk-over-TCP/IP, aka “DSI”). Unfortunately, the codebase rotted a bit and needed cleanup to run on current Linux and NetBSD releases.

Now that I’m retired, I have time to work on fun projects like this. I’ve spent the past few months refactoring the 2.2.6 codebase; it’s now at the point where I consider it good enough for public consumption.

I’m calling it “netatalk-classic”. It works out-of-the-box with NetBSD, and seemed okay on Linux once they fixed the Huawei commit that broke AppleTalk (as discussed at https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/ — full disclosure, I’m the guy that tried and failed to get the maintainer to fix the broken code that he himself had approved, so I’m a bit bitter).

Release tarball is at https://github.com/christopherkobayashi/netatalk-classic/archive/20200921.tar.gz and the GitHub source is at https://github.com/christopherkobayashi/netatalk-classic

Share and enjoy. Please drop me a line if you find this useful or need functionality that was removed.

Posted in Apple, Macintosh (m68k) | 2 Comments

LineageOS 15.1 builds for Sony Xperia Tablet Z LTE (pollux)

The LineageOS team is shutting down builds for 15.1.

Ari Opari has asked for Sony Xperia Tablet Z LTE (pollux) builds. They’ve been added to the rooster and are at https://lineageos.disavowed.jp/pollux

Posted in LineageOS | Leave a comment

LineageOS 15.1 builds for Huawei Honor 5X (kiwi)

At the request of Sachin Saini, I’ve added the Huawei Honor 5X (kiwi) to the weekly 15.1 build rooster. Share and enjoy.

Posted in LineageOS | 2 Comments

LineageOS 15.1 hammerhead builds working again

It looks like the LineageOS team got around to fixing what they’d broken in the hammerhead 15.1 tree. Builds have commenced.

Kudos to Uwe for giving me a heads-up — much appreciated.

Posted in LineageOS | Leave a comment

LineageOS 15.1 builds broken on Nexus 5 (hammerhead)

It looks like a commit last week to the 15.1 branch broke builds for hammerhead:

ERROR: /mnt/second/android/lineage15/packages/apps/LineageParts/src/org/lineageos/lineageparts/livedisplay/LiveDisplaySettings.java:401.60: config_enableLiveDisplay cannot be resolved or is not a field

I’m seeing discussion about this on other devices (https://www.reddit.com/r/LineageOS/comments/feuc3e/build_for_mako_fails, for example) that indicates that this isn’t isolated to hammerhead. It seems that devices that don’t have active maintainers weren’t updated to handle a feature change.

15.1 on hammerhead builds are going to fail until this is fixed.

Posted in LineageOS | 5 Comments

Making MacSSH work with current OpenSSH servers

The OpenSSH team has a habit of turning off ciphers/features every few releases. The rationale behind this decision is open to debate (this breaks compatibility with Cisco switches, for example), but so far they are only disabling by default rather than removing.

So long as it’s just disabled, it’s easy enough to re-enable. Here’s what to tweak when trying to connect a MacSSH client to a OpenSSH server:

  • Add this to sshd_config on the server and bounce the process:
Ciphers                         +aes256-cbc
MACs                            +hmac-md5
KexAlgorithms                   +diffie-hellman-group1-sha1
  • Create a profile for the server in MacSSH. You’ll want to turn compression completely off (it defaults to zlib).
  • If you’re using public key authentication, you must export the public key from MacSSH and run it through ssh-keygen thusly:
ssh-keygen -f ${PUBLIC_KEY_FILE} -i >> ~/.ssh/authorized_keys

That should do it. At some point I may hack a more current version of lsh into MacSSH to add new ciphers into the suite, but this works for now.

Posted in Apple, Macintosh (m68k) | Leave a comment