Example configuration xml tags are not aligned with yang modules

[saiakash1234]

I can see that example configuration provided is not aligned with yang modules inside the modules directory. eg: leaf private-key-format is not present in yang file

[Roytak]

What do you mean? The leaf private-key-format you're probably referring to is stored in the keystore and is generated as a part of the merge_hostkey script.

[saiakash1234]

Hi @Roytak , Thanks for the reply.

what I mean to say is example configuration files provided are not aligned with yang modules.

For example: below is the tls_keystore.xml provided in example configuration

<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
    <asymmetric-keys>
        <asymmetric-key>
            <name>serverkey</name>
            <public-key-format xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:subject-public-key-info-format</public-key-format>
            <public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3VrgFBOc/kZOADDFEs3dhktPJyB+EPkRSD1EnTDtlsrR0wG7HgAA+gdoEwbb2cqJxYH5hhUec0alDQ4l7PUe9ycw6L99ZsJsRTAAlcD0JhpgPngAuX24NVqQDv7Cg5Yx3BOS+Q0pO6GGyuOv2DczQ9BLYPAUAldaAIaa424YaJJ4oUNbS76FwqTs+WDaWtkqQRAqPa/9zg4hbiyCQpTbPNesU5GcTuWQpuuWpw1ZqXRKwJ92kYRNGCUYntJYwSdKnhukkEHYxMYVdfwaG3xFmPCDKy5OVBJmwuzWZC7KHrCK7yTzGZ7/izAWb+3JzhwYqhzq/ZF17eZWC/JDyUkBLwIDAQAB</public-key>
            <private-key-format xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa-private-key-format</private-key-format>
            <cleartext-private-key>MIIEogIBAAKCAQEA3VrgFBOc/kZOADDFEs3dhktPJyB+EPkRSD1EnTDtlsrR0wG7HgAA+gdoEwbb2cqJxYH5hhUec0alDQ4l7PUe9ycw6L99ZsJsRTAAlcD0JhpgPngAuX24NVqQDv7Cg5Yx3BOS+Q0pO6GGyuOv2DczQ9BLYPAUAldaAIaa424YaJJ4oUNbS76FwqTs+WDaWtkqQRAqPa/9zg4hbiyCQpTbPNesU5GcTuWQpuuWpw1ZqXRKwJ92kYRNGCUYntJYwSdKnhukkEHYxMYVdfwaG3xFmPCDKy5OVBJmwuzWZC7KHrCK7yTzGZ7/izAWb+3JzhwYqhzq/ZF17eZWC/JDyUkBLwIDAQABAoIBAHWhVFD290fc/ph1UlUi12UFYkPNrZDBeyCjhnHuTWQD1itG0TQpFlvIUdNCotSDIGG4J2zMjkj+MrnUWe0pedInnoMhN7fC/BxsXPM3/ca934Vy6heoqpqXzNRbJ+0bhNWKBWGaT94jgWkSRCEnfHO+HkCedFOmLer3nRndKNVwe+bHoXqnsXdOflc3mb71/BM/qfJI3GZBDTZaodTsS2LkuW4DTSNkxGqfZ0Bu1LyYm4mQ50/3nej9ILoT/ejnd17SPNpoBNnEyVJbExrk9pEoFPPKxQ3rCve7FE7y+ILmB4BdiSZm5lOyyJl1Y2Had6fZDubaNKACNWHMkdJ1GokCgYEA8dV97LUZbtgpMyKdzvAfSCXmGyRtucp2FXy5/9UXYU8MXMcOgbMpyrZLbfEwk0YMxKOw8nI4gCaSvIJb0Pek/agjaXIajoYvVIOhvDEq3+2JeT0eQh+9ue5bVOq65FHorDyRV64wwEucBN5CTCaEHdtEJY5WFkOzbrXVipjQxBsCgYEA6lJIm/Yzn92GQw/44XweoWtATtBwDDMvlWWQ8I7U5Rl6ZItPAGuaMmzDolAZjlRPoEPmxPpLKXYgCahkNnfPuuMgI8wA/65uZAqKfOuiGoIyj9oObJ/xb2zI3s4V8EwtfUE+lgg4D29/Cy33V9G6gHgl+CHjT00AZuvHTBsfwH0CgYAJyTXbSkjJL34bT59LLHRXmxEAsCywg/zbSbzNGXZkvaomZvezT+i1B0NuI4BvtTn3Cxix9uVKakUt06ibgCnxCcjFD5T7h3qK1PjKgMLXZOlXOp3q1xX6XCbd/NGrQ5VCwwCup6HZZjXeDJBqPHTEMIdFbckWBY9RP5JwlVZ9WQKBgCy/8iX26v0I7W85SaqmbaMePHXQ0NVDoT7C2t9WJ8ppBzrUcA4Afr5Kj0IcUgUgjORqk1PjCR+t84hkpF7SmtVyMt0jRL2Prn1klfYtehPd8ZIPbtnH4fAJsoL6kK4HnlhhcXZts2cfP//+k1IuN5P5Xib5MdQfPIhrVvBt7a5xAoGAH59S+aygEEIVf5pO8QmqQUpe3WbbuDvlAx3agP2jkeH5A7ZlxFpH7VJSGAoPIsX+nlixUH1P3Esw9ch7ByJ/JRFUX5+G5coTBQj+PAkyGKtmBmnBFxZydMpTdRMyDrKNKpeMZv7yn05YwnbZdS74L49mkY3pFrjRMDH1ltBxobk=</cleartext-private-key>
            <certificates>
                <certificate>
                    <name>servercert</name>
                    <cert-data>MIIDrDCCApQCFEf4LBXF80V6bTWn6kJ/RuccpJ/BMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJDWjEWMBQGA1UECAwNU291dGggTW9yYXZpYTENMAsGA1UEBwwEQnJubzEYMBYGA1UECgwPQ0VTTkVUIHoucy5wLm8uMQwwCgYDVQQLDANUTUMxEzARBgNVBAMMCmV4YW1wbGUgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGV4YW1wbGUub3JnMB4XDTIxMDkwMzEwMzAyMloXDTMxMDkwMTEwMzAyMlowgZMxCzAJBgNVBAYTAkNaMRYwFAYDVQQIDA1Tb3V0aCBNb3JhdmlhMQ0wCwYDVQQHDARCcm5vMRgwFgYDVQQKDA9DRVNORVQgei5zLnAuby4xDDAKBgNVBAsMA1RNQzESMBAGA1UEAwwJbG9jYWxob3N0MSEwHwYJKoZIhvcNAQkBFhJzZXJ2ZXJAZXhhbXBsZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDdWuAUE5z+Rk4AMMUSzd2GS08nIH4Q+RFIPUSdMO2WytHTAbseAAD6B2gTBtvZyonFgfmGFR5zRqUNDiXs9R73JzDov31mwmxFMACVwPQmGmA+eAC5fbg1WpAO/sKDljHcE5L5DSk7oYbK46/YNzND0Etg8BQCV1oAhprjbhhoknihQ1tLvoXCpOz5YNpa2SpBECo9r/3ODiFuLIJClNs816xTkZxO5ZCm65anDVmpdErAn3aRhE0YJRie0ljBJ0qeG6SQQdjExhV1/BobfEWY8IMrLk5UEmbC7NZkLsoesIrvJPMZnv+LMBZv7cnOHBiqHOr9kXXt5lYL8kPJSQEvAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAGIBnIrbkvRThfXyhWwf4522fTer4lP0znXCNuQ8/86irl6ZWMF2H0HuUha2g1mqAUjJPeM5x2PHr0Ulm3greKXmHl9Oto4SXPOO8tRD/tE09KRGiV/fk+MzFJqbMQj4Dq9P8yOxMMAj95RKN+fH2cIwOKSe8s3gPjldYDPOwIHZhWw3g0LCu/XVhNV2Os3wcWMx/ZWAvSfBUlldc5/dFW3vCy9UpcNj0lfs2LOcAx7R8mdd7wz/9iIZ6mE0OIh1alqKELAbf2hxX6WLoNCYZeVxixsbKhwgAG0XateRjkGjCy7V0q1dpOIs95stxRKNuOlFHXXyCBG1JzpPTfV+RL0=</cert-data>
                </certificate>
            </certificates>
        </asymmetric-key>
    </asymmetric-keys>
</keystore>

the yang tree generated from ietf-keystore.yang file from the modules directory is as follows:

module: ietf-keystore
  +--rw keystore
     +--rw asymmetric-keys
     |  +--rw asymmetric-key* [name]
     |     +--rw name                           string
     |     +--rw algorithm                      asymmetric-key-algorithm-t
     |     +--rw public-key                     binary
     |     +--rw (private-key-type)
     |     |  +--:(private-key)
     |     |  |  +--rw private-key?             binary
     |     |  +--:(hidden-private-key)
     |     |  |  +--rw hidden-private-key?      empty
     |     |  +--:(encrypted-private-key)
     |     |     +--rw encrypted-private-key
     |     |        +--rw (key-type)
     |     |        |  +--:(symmetric-key-ref)
     |     |        |  |  +--rw symmetric-key-ref?    -> /keystore/symmetric-keys/symmetric-key/name {keystore-supported}?
     |     |        |  +--:(asymmetric-key-ref)
     |     |        |     +--rw asymmetric-key-ref?   -> /keystore/asymmetric-keys/asymmetric-key/name {keystore-supported}?
     |     |        +--rw value?                      binary
     |     |        +--rw (key-type)
     |     |        |  +--:(symmetric-key-ref)
     |     |        |  |  +--rw symmetric-key-ref?    -> /keystore/symmetric-keys/symmetric-key/name {keystore-supported}?
     |     |        |  +--:(asymmetric-key-ref)
     |     |        |     +--rw asymmetric-key-ref?   -> /keystore/asymmetric-keys/asymmetric-key/name {keystore-supported}?
     |     |        +--rw value?                      binary
     |     +--rw certificates
     |        +--rw certificate* [name]
     |           +--rw name                      string
     |           +--rw cert?                     end-entity-cert-cms
     |           +---n certificate-expiration

from the xml and yang tree we can say that <public-key-format> <cleartext-private-key> <cert-data> tags which are present in tls_keystore.xml file are not present in ietf-keystore yang tree.

I hope you are able to understand my question.
Please let me know if I am missing something here.

[michalvasko]

What revision of ietf-keystore.yang are you using? It seems to be an old one, in the current netopeer2 version it is not even in the modules directory, all these YANG modules are now found in the libnetconf2 repository.

[saiakash1234]

Thanks @michalvasko for the reply. Tried using Latest repos now.

How to delete exisiting ietf-netconf-server, ietf-keystore, ietf-truststore configuration from sysrepo. I can see that there is an existing SSH configuration during bringup phase of netopeer server in the sysrepo even though repo was built with SYSREPO_SETUP:OFF

When I am trying to add tls config, the configuration is appending with existing SSH configuration but no overwriting it.

I am manually editing the configuration using --edit-vim. Is there any alternate command to delete / erase existing SSH configuration so that TLS configuation will be mergerd automatically.

Thanks in advance!

[michalvasko]

You can use -I <file> to import (replace) the configuration in the file.