non-unique resource names: systemd user services, ssh keys

[David Schmitt]

Hi,
as a follow-up to the recent non-unique package name discussion, I've
noticed two further instances where this is a problem:

* ssh_authorized_key, which is has only the comment ("name") as
namevar. This is obviously easy to avoid in practice, but might run
into weird edge cases, e.g. blocking proper purge support.

* systemd --user service instances. I'm currently experimenting with
user serviceable systemd instances. The current service type is not
able to model this at all. For example, I've would have multiple
"nginx.service" instances (one for each customer), each of which
receive notifications from different sets of other resources.


Regards, David

[Felix Frank]

On 03/17/2014 08:41 AM, David Schmitt wrote:
> as a follow-up to the recent non-unique package name discussion, I've
> noticed two further instances where this is a problem:
>
> * ssh_authorized_key, which is has only the comment ("name") as
> namevar. This is obviously easy to avoid in practice, but might run
> into weird edge cases, e.g. blocking proper purge support.

Good point. Note that crontab had different but related issues wrt.
purging. We came up with a workaround then that we can likely apply to
authorized keys as well, i.e. mangle the titles of generated resources
into a shape that is unlikely to clash with real-word resources (and
other generated resources).

Cheers,
Felix

[David Schmitt]

I've made a quick test and multiple namevars and title patterns do
interact like I have imagined they would:

I've enhanced the type I'm currently working on (see my recent mail),
by adding the second title pattern here:

def self.title_patterns
[
[ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ],
[:subinterface_number] ] ],
[ /^([-_\w\/]+)$/ , [ [:parent_interface ] ] ], # added
[ //, [] ]
]
end

and now the following notations work all as the respective comments
say:


pan_subinterface {
"ethernet1/5.17":
comment => 'title: ethernet1/5.17';

"ethernet1/5.18":
subinterface_number => '13',
comment => 'title: ethernet1/5.18;
subinterface_number: 13';

"ethernet1/5":
subinterface_number => '14',
comment => 'title: ethernet1/5; parent_interface:
ethernet1/5, subinterface_number: 14';

"flubb_53":
parent_interface => 'ethernet1/5',
subinterface_number => '3'
comment => 'title: flubb_53, parent_interface: ethernet1/5,
subinterface_number: 3';
}

Pan_subinterface['ethernet1/5'] and Pan_subinterface['ethernet1/5.18']
are very misleading titles in this specific case, but would be poster
childs for resources like cron or authorized keys, where the
non-colliding use case is much less confusing, because the title would
map to a command or comment.

Example using ssh_authorized_key:

# current situation
ssh_authorized_key {
# no user: key goes to root
"some_app":
ensure => present,
key => "...";

# specify user as property
"some_user_app":
ensure => present,
key => "...",
user => "flubb";

# unique title and name, specify user as property, comment will be
"flubb: power_key"
"flubb: power_key":
ensure => present,
key => "...",
user => "flubb";

# unique title and name, specify user as property, comment will be
"buzz: power_key"
"buzz: power_key":
ensure => present,
key => "...",
user => "buzz";

# title collision although configured for different user
"buzz: power_key":
ensure => present,
key => "...",
user => "froz";
}

# with title patterns and multiple namevars
ssh_authorized_key {
# no user: key goes to root
"some_app":
ensure => present,
key => "...";

# specify user as property
"some_user_app":
ensure => present,
key => "...",
user => "flubb";

# parse user "flubb" from title, comment will be "power_key"
"flubb: power_key":
ensure => present,
key => "...";

# parse user "buzz" from title, comment will be "power_key"
"buzz: power_key":
ensure => present,
key => "...";

# title collision although configured for different user
"buzz: power_key":
ensure => present,
key => "...",
user => "froz";
}

There seem to be some gains, but I'm not sure, whether they translate
to enough practical savings for the migration effort.



Regards, David

[Felix Frank]

On 03/18/2014 10:20 AM, David Schmitt wrote:
> # parse user "flubb" from title, comment will be "power_key"
> "flubb: power_key":
> ensure => present,
> key => "...";

This kinda made me frown. What would this manifest express then:

Ssh_authorized_key { ensure => present, user => "customer" }
ssh_authorized_key { "admin: masterkey": key => ... }

(Also, what would a user expect it to express?)

As for "migration"...this would be us looking at deprecating key names
of the proposed form first. Granted, those are unlikely picks, but any
user that *is* afflicted by such a deprecation will have to make some
handstands to cleanly move to a different naming scheme.

Felix

[Trevor Vaughan]

I agree that this is a practical solution, but it feels too much like magic to the end user.

Instead of being a listing of key/value pairs, it's now a relatively arbitrary combination of fields that don't have any inherent meaning.

If the types can't be fixed properly then I don't see another way of doing this, but it certainly sets off my usability alarms.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/e7a6f4a7451dcf0704e39062fa34be79%40hosting.edv-bus.at.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[David Schmitt]

On 2014-03-18 10:33, Felix Frank wrote:
> On 03/18/2014 10:20 AM, David Schmitt wrote:
>> # parse user "flubb" from title, comment will be "power_key"
>> "flubb: power_key":
>> ensure => present,
>> key => "...";
>
> This kinda made me frown. What would this manifest express then:
>
> Ssh_authorized_key { ensure => present, user => "customer" }
> ssh_authorized_key { "admin: masterkey": key => ... }
>
> (Also, what would a user expect it to express?)

This is indeed ugly. I've only discovered the current behaviour by
experimentation. This is definitely something that should be fixed in
one way or the other:

* title matches take priority, or
* properties set directly and via title are forbidden.

> As for "migration"...this would be us looking at deprecating key
> names
> of the proposed form first. Granted, those are unlikely picks, but
> any
> user that *is* afflicted by such a deprecation will have to make some
> handstands to cleanly move to a different naming scheme.

Now that I think more about it, I feel obliged to point out that adding
a second namevar and adding title_patterns are two separate issues.

Adding the namevar (and - IIRC - changing the Type#name getter) without
adding title_patterns for comment AND user syntax would create this
situation:

# with multiple namevars, but no title pattern
ssh_authorized_key {
# no user: key goes to root, use title as comment
"some_app":

ensure => present,
key => "...";

# specify user as property, use title as comment
"some_user_app":
ensure => present,

key => "...",
user => "flubb";

# potentially conflicting resources

# specify user as property, use title as comment

"flubb: power_key":
ensure => present,

user => flubb,
key => "...";

# use title without specific meaning
"buzz: power_key":
ensure => present,
user => flubb,
comment => power_key,
key => "...";

# use title without specific meaning, collision with last resource
because of title
"buzz: power_key":
ensure => present,
user => froz,
comment => power_key,
key => "...";

# use title without specific meaning, collision with last resource
because of properties
# not tested empircally
"froz: power_key":
ensure => present,
user => froz,
comment => power_key,
key => "...";
}

This becomes more verbose, but would not require a migration. Having
written it down, I'm not sure what multiple namevars would bring to the
table. From my amateurish reading of Puppet::Type, they are used
internally to automatically distinguish resources. The code around this
is not very clear, or clearly documented.


Regards, David