@hagbard If rewrite can be done in a reasonable time (days to a couple of weeks), I think trying to clean up old code is more trouble than it's worth.
With big stuff that cannot be easily rewritten, it may be worthwhile.

Thanks for your comment. I read the wiki page already, but wasn't sure how to proceed. How do I assign myself to a task? I didn't find an option in phabricator to do it. I think I don't have permissions for it unless I created the task, I suppose.
I did dive through the majority of the existing code and am about to do some cleanups and therefore rewriting major parts. As far as I understand, that's the long term plan anyway until 2.0 can be released.
Let me know if it doesn't make sens to do surgery on the open heart, since it's going to be remove at one point anyway. Otherwise, I would check and see how I can become most useful to the entire project in general.

@mb300sd Can you please share your config for the bridged interfaces?
I did a few tests and can't find any issues.

@hagbard If you are working on it, by all means, assign it to yourself. We do not have a formal assignment policy, it's more like "I'm working on it" flag for coordination.

I looked into ti, the xml is fairly easy, the perl code pretty nasty, it also refers (hardcoded) to sysV initd.
In my opinion it's almost impossible to convert the perl code into python without getting eye cancer, I think the python code needs to be written from scratch (will be invisible to the enduser on the cli, options will be the same)
Let me know if you need more details, I'm more than happy to discuss my finding.
The complete rewrite won't too long either, but hard to estimate due to the fact that the original code used libs and has different scripts for config and op commands.

@runar The sudo wrapper is mostly due to the fact that the op mode convertor is largely a clone of the conf mode convertor. This also interfers with operator level users' ability to run anything at all, so this is a good point.
We likely need to switch to adding sudo where needed instead, but we need to test which commands break from it when run by non-admin users.

I'm looking into it. (not sure how I could assign the task to myself?)

When trying to migrate " show login " and "show history" the new syntax scripts fails to retrieve information from the current user.
The reason is that everything that is executed by the new syntax scripts are wrapped inside sudo.
(from build-command-op-templates line 140: node_def += "run: sudo sh -c \"{0}\"\n".format(command.text) . )

Thanks Christian, that helps a lot. I was assuming I only need to generate configs if I really write config data int oa local file, so I have something to compare.
Thanks again, still need to play with it a little, but I think I understand now the parts of it.

Create/update/delete are all called implicit by the execution of the given Python script.

Added a child feature request for iPXE.

+1 here as for small ISP.
Needed features (at least):

• choose interface to listen on
• choose directory to serve
• toggle read-only/read-write access

Would-be-great features:

• View connections log
• View current connections

Sorry I got stuck a little.
I have the interface definition written, using the new recommended style. However, create/delete and the such need to be handled in a script.

@Asteroza can you add the approriate Task here in the comments?

If you are going to do this, then there's the related issue of whether or not to put in PXE/gPXE/iPXE related stuff to support netbooting things.

I agree that this is a good idea, especially for small offices.

By this you mean VyOS should act as TFTP server and provide files to clients?

seems never was picked up for use, closing

If you look on centos, it will not give you set ip (and up interface) with ip which exist on net
i agree that all should have address plan, but reality is a bitch

This would make sense. Some could imagine that there is a P2P linkt between two sites and a WAN IPSec Backup link

We should rewrite legacy DDNS first and then could add aws53 as alternative provider that would make sense.

Hmm I'm wondering b/c I've seen a provider in germany (HETZNER) where they do NAT (not PAT) for their cloud customers. Every vServer has the same IP configuration with RFC1918 addresses and an outside router does the mapping. Implementing this would break such a szenario if it can't be disabled.

@syncer we can put the changes into the image after T650. I'll work for T650 tomorrow.

@c-po kind of candidate for new xml thing

no feedback

@afics add correct description to this task

We may want to extend this

@higebu have a time to chat on this.
i think we need to add several changes to image specific to vmware (we want use custom config there)

Reopening this,
we not going to keep all old staff there
just like system gateway, this must be removed

@c-po do you think it's something easy to implement?

ok thanks for your work and explanations

We can't do anything about the truncated encrypted-key b/c it's actually truncated by SNMP itself.

I tested update from vyos-1.2.0-rolling+201806060337 to vyos-1.2.0-rolling+201806070337, went fine.
Then I tested update from vyos-1.2.0-rolling+201806040337 to vyos-1.2.0-rolling+201806070337, went fine too , even without 'listen-address'.
Looks good. Only the truncated encrypted-key in privacy is still there.

Issue should be fixed starting with vyos-1.2.0-rolling+201806062125-amd64.iso at least it was tested positively when updating from 1.2.0-rolling+201806040337 to 1.2.0-rolling+201806062125

ok if you need tests or info, please ask

Okay, when not executing the marked part (https://github.com/vyos/vyos-1x/blob/743b16de1aac4c6b579767f28d57bc2156d3acdf/src/conf_mode/snmp.py#L704-L729) reboots work but then we loose transformation from plaintext o encrypted passwords. So the bug is definately here. Will check!

Okay, when rebooting both encrypted keys change, thats a bug in the Python script too ... sorry for the trouble.

Okay, there was definately a problem with the listen address which is fixed now. Waiting for a new ISO and then I try upgrading from old version, too

Thanks @hagbard

Interface definition is the last piece which needs to be done, should happen this week.

then I deleted the encrypted-keys, set plaintext keys, commit, show config shows encrypted-keys (the privacy key again truncated), and snmpwalk works now. So it is a migration problem if someone just updates his router to rolling version from today.

i set this, got the following messages:

Looks like there is no listen address agentaddress unix:/run/snmpd.socket configured and if there is none inside the configuration, we won't listen on all addresses. This is likely the cause. Could you please add for validation a set service snmp listen-address <ipv4> and check if you can now reach the server again?

Could you please paste the content of the following files:

Yes is running:

Could you check if the snmpd process is running at all? Please execute ps faux | grep snmp in the commandline.

I have updated from VyOS-1.2.0-rolling+201806040337 to VyOS-1.2.0-rolling+201806060337 with the same config (the one I sent you before). But now I cannot get SNMP info from this VyOS installation anymore (timeout).
What can I test next?

@Line2 new ISO building right now which converts plaintext-keys to encrypted keys again.