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.

I'm not happy with the current one. Ideally, I'd like to rewrite it in Python using better diagnostic collection tools. I don't see it happening in 1.3.0, however.

This is no longer relevant now that curl has been almost entirely removed from the interface. Source addresses and such can be set for commit-archive, and authentication variables are set individually for each session.

I'm going to delete loadkey from 1.4 some time after 1.3 comes out.

I assumed the last element of .history[] is the final URL, so I had it display .history[-1]; but it turns out it overwrites .url with the final destination and only keeps the previous redirects in .history[]. Now it just displays .url if .history[] is not empty.

The way it's done right now is like this:

curl is no longer relevant as it was superseded by the new remote module.

Assuming it does not (and I can't replicate this), since the responsible code was rewritten in November to properly use low-level sockets. Let me know if it still persists and I'll try to poke around Paramiko for performance bottlenecks.

Going to backport this to 1.3 as well.

Does this problem persist with the latest rolling version?

The way sockets are handled in the last version should've fixed this once and for all.

Less scary error messages are produced now.

Still works perfectly fine for 1.3 nightly. (1.3-beta-202111240443)