scp seems to work for me. Now, I'm not using any fancy modern keys, so it just RSA in my quick test.
It's always /app DNS.
On /app, it's the lack of DNS. The issue is container IP is dynamically assigned, and sometime reassigned. While there are the [placeholder] variables that work inside the same app. What you run into is the container names are not in DNS, even for other containers.
The issue is you may have one /app that uses another /app's services. Taking caddy as example, you may want to use that as a proxy to some enabled babybuddy app. The problem is caddy has no idea of babybuddy container's IP to know where to proxy to. While workarounds in various areas (like using external port if all is on internal bridge), that does not cover all the cases where a stable name for /app's IP is needed.
Anyway, I think the /app's VETH should be added as "dynamic static DNS" entry so /ip/dns resolves a container's VETH's IP. Otherwise, /app can easy change container IPs that have be updated manually elsewhere.
Note to readers: Despite my many comments on /app, it generally works-as-advertised (e.g. /app/enable X then perhaps adjust some env var as needed). So don't let the volume of my comments mean "it does not work", more there are corner cases that need improvements.
Can you think of any compelling reason to switch from container to app for something like Caddy? Iâm currently running it as a container on the single disk I have in my ROS VM. I noticed that app seems to require a second disk to be selected when itâs turned on, so I think for the moment Iâm better off just keeping caddy running under container as I donât really need any appreciable space for it and my snapshots and backups currently happen in just a few seconds which is very convenient.
If your container is working and youâre happy with it, leave it alone.
/app is nice but it still undergoing a lot of changes. Unless/until you have a need to use some of /appâs automations, you have more granular control of things in /container, and any testing you do in /app wonât mess up your container (unless you give it the exact same storage location, etc.).
2 Likes
Agreed. I'd add given caddy has many features, /app's current port mapping scheme may not be flexible enough to express exactly what/where you want stuff exposed. And imagine still needing custom firewall rules, which then get more complicated since you may potentially "unwind" the /app dynamic rules.
caddy is actually not best use case for /app IMO. Since one benefit of /app is you can combine multiple [smaller] containers focused on specific needs, so the "all-in-one" nature of caddy goes against that. Also caddy uses a config file, but the new /app scheme does work better when things are based on ENV variablesâĄ, since those are editable in WinBox/WebFig to customize things.
⥠Now, /app does let YAML add config files, and the config files are exposed as mounts automatically, so it's not too bad. And MikroTik could offer a tab to edit any /app associated config files in UI.
1 Like
I wish the YAML could be changed, and then the /app could be staged to repull based on the YAML changes with a special update button, such that it doesnât restart the container immediately when you hit Apply.
1 Like
Yeah I found this irritating earlier when i was messing around. still funky though!
One trick is you can use /app/settings set app-store-urls= from your PC via something like npx serve/ python3 -m http.server within a directory with your /app YAML. This is what I've been doing to test things, since I can use VSCode to edit the /app, but also get validate/competion of the /app syntax, which is the picked up indirectly via app-store-urls.
I'm not sure it's polling interval, but if you just edit app-store-urls it will repull the custom app definations. Also the YAML does need be structured with an array (-\n+2 spaces, then app YAML) for the YAML to be loaded by app-store-urls.
But agree it should be editable in WinBox/WebFig. Or, the full set of options in YAML being expressable as RouterOS syntax.
This worked on CHR. But when I tried on MMIPS-based hEX S, the iPhone does not appear. I haven't tired MIPSBE, ARM32 or ARM64 yet.
But is it limited to only some platforms? Or should it work on MMIPS/etc?
1 Like
I'm still not sure on the move and place-before= scheme used. The makes adding rules trickier since now you need to use find or other tricks to ensure new rules gets placed correctly. While trivial in WinBox/WinFig to place a new rule correctly, the "place-before= scheme" (e.g. firewall) is much harder for automation to update config, which is where my concern lie.
Perhaps, there should be some new priority= (or order=) that controls the rule order, similar to VRRP's scheme. The idea being is you can add rules using a numerical value in the add/set, and assuming a rational scheme for the default rules, you'd always know the position (and default priority= keep same logic).
This also allow allow more complex user routing rules... since you can add them with a certain priority according to your own scheme to effect placement. While Linux may not have notion of "priority", you'd apply the priority to order them before commiting rules to kernel.
Yes, in the corresponding Linux feature âip ruleâ there is such a âpriorityâ field and the built-in rules have priorities like 0 or 32767 so user rules can be placed between those.
Well then...all the more reason. If we're exposing things in routing rules... priority should be one.
1 Like
Since there's no response yet, I'd like to discuss the issue. I've attached a capture of prefix 5.5.5.5/32 on VRF vrf-trial-test_ received by PE (CCR1009 with software v7.22.beta6 & 7.23_ab250), the prefix 5.5.5.5/32 originates from a loopback interface on CE and is advertised to PE. Here are 2 prefixes shown, the top one is the prefix 5.5.5.5/32 sent by CE using iBGP multihop config (update source loopback PE peering with loopback CE), and the bottom one is the prefix 5.5.5.5/32 sent by CE using iBGP non-multihop.
The prefix 5.5.5.5/32 from non-multihop iBGP peering is successfully advertised to other PE via RR, but the multihop one (top capture) isn't. From the capture, is there anything wrong with the prefix 5.5.5.5/32 from multihop that's preventing it from being advertised to RR/other PE? Is this a bug or a misconfiguration? The same multihop config has been tried using Cisco 3800 series as PE and the prefix 5.5.5.5/32 is successfully advertised to RR/other PE. Looking forward to your input.
Since 7.22beta5, creating a new wireguard interface shows only a public key with no private key shown or saved. The public key is replaced with a new one on reboot, breaking peer connectivity.
Any working interfaces present when upgrading from previous versions are preserved properly.
Emailed support.
1 Like
Ive got issue where I have a double interface., tmp is flashing constantly between enable/disable.
Reverse proxy for home assistent container:
wan url: https://home-assistant.XXX.routingthecloud.com/ returns a HTTP Error 400 bad request
lan url http://192.168.11.13:8123/onboarding.html is ok
Something is wrong with that reverse proxy.
You might want to check /ip/service/print, and see if the reverse-proxy is enabled. IDK if the automatic use-https=yes with "routingthecloud.com" automatically enables it.
This is due to:
https://www.home-assistant.io/integrations/http/#reverse-proxies
we will add some configuration in app to change it automatically.
/interface/veth print should show ip address used by Home Assistant, use that for connecting to this up while we fix it.
1 Like
Thank you for the report, the issue will be fixed in upcoming RouterOS testing version!
1 Like
Hmm...
Looking only at this screenshots, these attributes seem strange to me!
- Which IGP are you using to propagate the Underlay Loopback routes?
- Could you share the MPLS L3VPN route equivalents for those routes?