| Blog |
|
| Releases |
Page:
0 1 2 3 4 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100 ... 105 ... 110
| VNC + Ubuntu 22.04 | |
|---|---|
|
Date: 3/5/2024 Tags: linux remote-desktop | My local Linux server is Intel Nuc running Ubuntu. A few months ago I upgraded from 18.04 to 22.04, seemed like a reasonable thing to do. In the process I lost the ability to vnc into the server and use the desktop graphically. Originally I was using this command to run the vnc server:tigervncserver -geometry 2400x1350 -depth 24 -localhost no :1 Worked wonderfully on 18.04. Not so much on 22.04, something to do with the gnome session not starting up after the VNC connection was established. I spent hours and hours over the course of the last few months trying to debug that. But got nowhere. The logs didn't give me anything useful, and my google searches for various errors were all dead ends. Then I had some success with using the built in gnome-remote-desktop features (accessed from the main settings app's sharing -> remote desktop -> ...) on my 22.04 machine at work. So I thought today... "I'll try that!". It did not go well. Firstly after enabling it and attempting to connect all I got was a hung connection. No window appeared on the client end (Windows 10). I knew it was running because I checked it was listening on the right port: matthew@nuc:~$ sudo lsof -i -P -n | grep 5900 gnome-rem 22207 matthew 10u IPv6 249744 0t0 TCP *:5900 (LISTEN) Nice, good to know. But what is 'gnome-rem'? matthew@nuc:~$ ps -A | grep gnome-rem 22207 ? 00:01:11 gnome-remote-de Ha, slightly more info. matthew@nuc:~$ ps -fp 22207 UID PID PPID C STIME TTY TIME CMD matthew 22207 1075 6 11:11 ? 00:01:11 /usr/libexec/gnome-remote-desktop-daemon Ah, so what is 'gnome-remote-desktop-daemon' anyway? matthew@nuc:~$ dpkg -S /usr/libexec/gnome-remote-desktop-daemon gnome-remote-desktop: /usr/libexec/gnome-remote-desktop-daemon Ok so the 'gnome-remote-desktop' package is what's providing the actual functionality. So what else is in that package? matthew@nuc:~$ dpkg -L gnome-remote-desktop /. /usr /usr/bin /usr/bin/grdctl /usr/lib /usr/lib/systemd /usr/lib/systemd/user /usr/lib/systemd/user/gnome-remote-desktop.service /usr/libexec /usr/libexec/gnome-remote-desktop-daemon /usr/share /usr/share/doc /usr/share/doc/gnome-remote-desktop /usr/share/doc/gnome-remote-desktop/changelog.Debian.gz /usr/share/doc/gnome-remote-desktop/copyright /usr/share/glib-2.0 /usr/share/glib-2.0/schemas /usr/share/glib-2.0/schemas/org.gnome.desktop.remote-desktop.enums.xml /usr/share/glib-2.0/schemas/org.gnome.desktop.remote-desktop.gschema.xml /usr/share/gnome-remote-desktop /usr/share/gnome-remote-desktop/grd-cuda-avc-utils_30.ptx /usr/share/gnome-remote-desktop/grd-cuda-damage-utils_30.ptx Alright... hmmm, grdctl? What is that? matthew@nuc:~$ grdctl --help
Usage: grdctl [OPTIONS...] COMMAND [SUBCOMMAND]...
Commands:
rdp - RDP subcommands:
enable - Enable the RDP backend
disable - Disable the RDP backend
set-tls-cert
At this point I played around with the vnc settings, setting a password... trying the set-auth-method options etc. Not much changed. So I thought well... it's "Open Source" right? I could like... GET the source and have a look right? matthew@nuc:~$ /usr/libexec/gnome-remote-desktop-daemon --version GNOME Remote Desktop 42.9 Ok, googled the source archive for that and got this. Download and unpacked that onto the nuc server and had a look. Fairly standard meson package... nice. So I mkdir'd a build folder and installed meson. It complained there were many missing libraries. So I worked my way through them all, using apt-cache to find the -dev lib and apt install'ed each of them. Finally I could build gnome-remote-desktop locally. From the build folder I found an x64 binary: ./src/gnome-remote-desktop-daemon Perfect. Ok, lets stop the system one: systemctl --user stop gnome-remote-desktop And to make seeing the logging easy I decided to co-opt the logging to just printf to the screen. So in src/grd-daemon.c, the main function, I added: g_log_set_default_handler(printf_log, NULL); Where 'printf_log' is defined as: void printf_log(const gchar *log_domain, GLogLevelFlags log_level, const gchar *message, gpointer user_data)
{
printf("%s:%i:%s\n", log_domain?log_domain:"-none-", log_level, message);
}
Super simple, but makes all the logging way easier to see. Now that that works. I ran ./src/gnome-remote-desktop-daemon and tried to connect. Still no joy. But I was getting a 'New VNC client' in the logging. So kinda hopeful right? Well I greped the code and found the 'handle_new_client' function. Nice, it seems to get the auth method and handle it. First things first, lets log the auth method so I know what we're dealing with. It was GRD_VNC_AUTH_METHOD_PROMPT. Ok. Well what if we tried GRD_VNC_AUTH_METHOD_PASSWORD? How do I change that? Well... remember that grdctl tool? grdctl vnc set-auth-method password Run it again... and this time the client asks for a password! Hurrah... seems like I'm making progress. However once the password is entered the client says "unexpected error". So where are the credentials checked? check_rfb_password seems like it does that. And reading through that found: memcmp (challenge_encrypted, response_encrypted, len) I added some logging and checked the result... and? It's ok! The password checks out as correct. But yet... the client complains. Interesting. Something in the logging caught my attention: -none-:16:Failed to record monitor: GDBus.Error:org.freedesktop.DBus.Error.Failed: Unknown monitor A little googling of that error resulted in finding some forum posts about how the backend doesn't want to function on a headless machine. Which is not great, but at least I could try plugging a monitor in. So I grabbed a long HDMI cable and plugged it into my PC monitor's second port... just so it's attached to _something_ rather than nothing. Tried to reconnect and .... SUCCESS! A remote desktop! 
I have bought a little HDMI display emulator to trick it into thinking there is a monitor. And maybe someday it'll run headless properly... but I think for the moment I'm just happy it works at all. Open source is great... and a pain all at the same time. I doubt I'd even have this trouble with Windows or Mac. It does just seem to work out of the box a little better. |
| (0) Comments | Add Comment | |
| Scribe 3.2 | |
|---|---|
|
Date: 11/10/2023 Tags: scribe | So I've released Scribe v3.2, not so much because I finished testing all the things, but because I need some usability feedback. And it's been too long since a release. Somewhat disappointingly the size of the Linux build seems to have grown alarmingly without any good reason:  Yeah that's not a typo. And I have looked into it, all the basics like "is the binary built with -Os?" and "is the binary striped?" etc. And nothing obvious stands out. I would love a second opinion on this... just to sanity check the Linux build and see if I'm doing anything dumb? |
| (1) Comment | Add Comment | |
| Website CSS / Scribe | |
|---|---|
|
Date: 13/4/2023 Tags: website scribe | I've removed the fixed point sizes in this sites CSS so that the font size is free to adapt to the user's settings and screen DPI. Hopefully that'll improve the readability somewhat. I'm slowly working my way through a large backlog of Scribe UI testing. So that when I release v3.2 I'm reasonably sure that things aren't horribly broken. Because at this point, I'm finding that lots of things aren't working right. But at least now there is some visibility into my progress. |
| (1) Comment | Add Comment | |
| Scribe native export | |
|---|---|
|
Date: 8/3/2023 Tags: scribe | There has been a long running branch of Lgi and Scribe to remove the old synchronous way of doing dialogs as part of the work to re-enable Haiku support. And I decided the cost of keeping the branches separate was too high and merged all those changes into the main dev branch of those projects a few weeks back. This means that a bunch of old functionality that I haven't touched in a long time is now broken. For instance the Scribe mail3 export function. So I spent the last few days fully re-writing that to use the modern patterns and also optimize things a bit. Which has all been reasonably successful. It even has a nice new completion dialog: In that example I'd run it earlier and the replication had nothing to do. It's designed so you can use it to backup your folders and it's reasonably intelligent about replication of items. In terms of when there'll be a new release. There are a bunch more dark corners of Scribe that I never test, and they all need to be looked at. I'll keep working me way through them. |
| (1) Comment | Add Comment | |
| i.Disk on Haiku | |
|---|---|
|
Date: 20/2/2023 Tags: i.Disk | 
|
| (0) Comments | Add Comment | |
| Phabricator fork and the Scribe code base. | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Date: 3/5/2022 Tags: scribe opensource | No one cares, but the announcement on 1st April wasn't a joke. Scribe is actually going open source. It's just taken way longer than I expected to create a new mercurial repository and have the hosting work correctly. Part of the issue is that my Phabricator install was misbehaving and it took a while to fix. I've had to create a fork of Phabricator and fix the passing of arguments to hg's web-server. I also had to clear out all the proprietary stuff in the Scribe code base, do some cleanup and get it all building again. Mostly that boils down to the OAUTH2 client secrets (good bye Gmail support) and the InScribe key checking code. That work is mostly complete now so I can publish the code base. It lives here: https://phab.mallen.id.au/source/scribeopensrc/ I'll be adding some more info on how to get it to build and updating the Scribe home page over the next few weeks. But it's slow going cause I have very little energy at the moment. I'm on day 14 since I got my first covid symptoms. Which have all cleared up bar the tiredness. Fortunately no one else in my family got it. Oh yeah, I've moved the versioning for the open source tree to "v3.x.x" just to make it clear where the new builds come from. The v2.4.22 changes will be rolled into a v3.0.0 build soon. As I won't make that build off the proprietary code base. Well ok, but how do you build it? hg clone https://phab.mallen.id.au/source/scribeopensrc/ code/scribe/trunk python code\scribe\trunk\build.py Should get you most of the way there. That currently just supports Windows but I will extend that support to other OS's as soon as I can. Requirements look like:
| ||||||||
| (2) Comments | Add Comment | |||||||||