[Migration] Wildcards in .cloginrc

[casdr]

Hi,

I'm using wildcards for authentication in .cloginrc, example:

add user *-client1 user1
add password *-client1 pass1

add user *-client2 user2
add password *-client2 pass2

It would be great if this could work with the migration tool.

[ytti]

@FlorianDoublet

I had this in one project, which supports globs for cloginrc.

module DNA
module JunOS
class XMLSSH

  class CLoginRC
    class FileNotFound < Error; end
    class KeyNotFound < Error; end

    def initialize host=nil
      file    = File.join Dir.home, '.cloginrc'
      @host   = host
      @host ||= '§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§' # poison the name, to avoid mathchin unless '*' glob
      @rc     = File.read(file).lines
    rescue
      raise FileNotFound, ".cloginrc not found in hoemdir"
    end

    def user
      find_key 'user'
    end

    def password
      find_key 'password'
    end

    private

    def find_key want_key
      @rc.each do |line|
        items  = line.split
        key    = items[1]
        next unless key == want_key
        glob   = items[2]
        result = items[-1]
        return result if File.fnmatch(glob, @host)
      end
      raise KeyNotFound, "#{key} was not found in .cloginrc"
    end
  end

end
end
end

[casdr]

That looks interesting. Where do I have to place it?

[ytti]

Sorry, I wasn't being very clear. I more intended it to @FlorianDoublet, as he wrote the migration tool. You can't add the file anywhere, similar logic, mainly File.fnmatch(glob, target) would need to be added in the migration tool.

[casdr]

Ah, thought so. @FlorianDoublet keep me updated. Will try to fix it myself and contribute it back too when I'm back at the office.

[FlorianDoublet]

Hi @itscassa, the problem is that i'm not in a company anymore, i'm still a student, and then for the moment I can't test oxidized on anything in my home..

[supertylerc]

@casdr: did you get this working? If so, would you mind submitting a PR for it? Thanks!

[casdr]

@supertylerc Unfortunately not, I copy-pasted the credentials instead

[ytti]

I have mixed feelings for this. I personally imagine companies have some source of device information, HTTP or SQL, and they can use that directly, i.e. the original truth source, so to avoid maintaining multiple places. But I guess for some people the authority is .cloginrc? And no where else is this information available?

If there is some truth source, which we currently cannot use, then I'm more interested in adding support to that.

Some middle-ground might be script in /extra directory, which creates database of nodes, based on .cloginrc. I guess it wouldn't be very hard to accept password in config to be be a hash, with regexp key for device name and password value. But dunno, seems iffy to me, not to have reasonable truth source for data.

But obviously, ultimately it is the user who dictates how they want to run their stuff. I'm not gonna do this, but I'm open to PR.

[supertylerc]

The bigger problem in my (very brief) testing is that you can't import a RANCID router.db without the .cloginrc file. I spent a lot of time trying to figure out why my RANCID migration was failing. So if my RANCID router.db looks like this:

rtr1.example.com
rtr2.example.com

And my .cloginrc only has an entry for rtr1.example.com, then my resulting Oxidized router.db will not have an entry for rtr2.example.com.

I agree that companies should have sources of truth, the reality is that many don't. Sometimes it's because of budget, sometimes it's because an engineering team owns its own lab that has an inventory system but doesn't expose credentials.

But again, I think that the larger problem is that if you want to migrate your RANCID infrastructure to Oxidized, your only option is to do it manually or use the migration tool. Since it seems to require valid entries for every device that gets migrated, and since the Migration tool requires a .cloginrc, you need to have the appropriate entries in your .cloginrc if you want to migrate a RANCID router.db.

I could make it so that .cloginrc is not required.

[howardjones]

Greetings from the future :-) I've just run into this same issue... for us it's that RANCID has its own account in ACS for some devices (which is different from what we'd use for normal config work), and then some devices have specializations (for things like "must use a certain cipher"), or local accounts for remote devices, with a final * entry at the bottom for business-as-usual ACS-registered devices with no special needs.

Before I found Oxidized, I did start writing a Python tool to manage RANCID configs. I'm pretty sure it included code to give you a complete set of the 12 or so RANCID per-device settings, given a hostname, including following include directives (we use those to break up the config for different groups). I'll see if I can learn enough Ruby to make it work, and perhaps make a PR.

[howardjones]

This wouldn't be so bad if the migration tool didn't also create a router.db which oxidized can't load... At least I assume that's what is happening. If I press Reload in the web ui after a migration, I get a "Unable to reload nodes" warning, but no information in the log to say why that might be.