After some research, I have concluded that the error was caused by the string's violation of RFC 3986, which recommends using percent encoding instead. I'll look into the feasibility of implementing percent encoding/decoding (which urllib natively supports) for spicy characters if there's demand, but the recommended method in VyOS right now is using the protocol-agnostic REMOTE_USERNAME and REMOTE_PASSWORD environment variables, which bypass the URL decoding step. The alternative would involve messing with urllib.parse's internal parser to implement a laxer and less greedy regexp to accept passwords like this, which is probably a bad idea.

T4516 adds this functionality.

@trae32566 Are you experiencing this with the latest rolling version? 1.5-rolling-202312130023 was released mere hours before the fix was pushed. See also: T5774

KeyboardInterrupt is caught with an appropriate error message now.

Oops, wrong task.

show tech-support report was rewritten in PR 1961 and the last vestiges of the original was removed earlier in PR 2260. See T5137.

show-dhcp-leases.pl under vyatta-op remains the only extant deadweight Vyatta script and needs to be removed.

If the script returns nothing, the raw mode returns "". Is this expected behaviour? Should it not be {}?

Removing the deprecation notice from 1.4.

This seems to be Cloudflare's doing, not ours. We're investigating this issue.

Note: Equuleus still uses the C preprocessor. // substrings (otherwise interpreted as comments) were escaped as \/\/ in op-mode-definitions/generate-public-key-command.xml.in in Equuleus and should be converted back eventually.

I'm going to be experimenting with Jinja 2 to see if we can incorporate it into our template processor.

Actually, let's leave it in 1.3 but backport the warning and generate public-key-command.

I'm removing loadkey from 1.4. It will be removed from 1.3.1, as well. Eventually, the warning will be dropped from 1.4 but it will remain in 1.3.

Chained exceptions are covered too (and backported to Equuleus).

Pythonic reimplementation complete. Now only the XML op-mode definition and the auto-complete script remain.

Some notes:

1. The old syntax is quite terrible. It breaks if an image is named disk-install or running or any remote protocol. There needs to be a cleaner syntax for it, such as copy file from image My-Image/usr/local/foo to path /tmp/foo or show file in remote ftp://ftp.example.net/foo.
2. 'Image tools' isn't exactly a descriptive name for it. It does four operations:
   • show: List files in a directory, or spit information about a file followed by its contents (hexdump if it's binary).
   • copy: Copy a file or directory from one place to another (it can merge directories).
   • delete: Deletes a file or directory (doesn't work remotely).
   • update and updateone: Updates an image's config directory with rsync (the only part directly related to image manipulation). This is actually called clone in the CLI.
3. show, copy and delete should probably be moved to a separate (new) module related to file operations (and coupled with vyos.remote) whilst update needs to become its own thing (a helper script, perhaps).

If anyone actually wants support for source port parameter, feel free to reopen this, but the interface parameter is a no-go. In the meantime, rewriting vyatta-config-mgmt takes precedence.

That's a good idea. What remains in that repo was hardly touched in a decade.

I personally think the interface part is high-effort, low-gain since you can simply use the address of the interface to the same effect, whereas simply providing an interface will force it to decide which address to use on dual-stack systems. It needs to pick between AF_INET and AF_INET6 when creating the socket before setsockopt()ing SO_BINDTODEVICE; although I think we can get away with doing what socket.create_connection() does. Even then, only the SFTP portion of the code directly uses socket — everything else relies on higher level libraries that only expose address and port options. (Also, using a single parameter for both addresses and interfaces is a bad idea, in my opinion, because it's probably more useful to resolve an FQDN string to an address rather than assume all strings are interfaces. But otherwise, we'd need to find a way to resolve conflict between address and interface parameters.) All in all, I don't think the interface parameter is a good idea at all but we'll see.

All parts completely backported to Equuleus.

I opened a new issue for this: T4090.