Add a sysctl resource

[iamzhout]

Description:

I've read mgmt blog posts and video introduction, and didn't see this use case as in title, that if I want to keep some kind of os kernel related settings, does it supported currently by mgmt config?

[purpleidea]

@iamzhout We don't currently have a resource for this, but we are happy to add one or get a patch for it. It's easy to get/set values. The real question is: how can you detect when one of them has changed without simply polling constantly.

If you can research this for us, and report back here, we can help you write a resource!

[iamzhout]

@purpleidea sorry for late response, it seems to me that it is hard to be noticed of change without periodic polling, the way I can think of is to run sysctl -a and get those configurations of interest. I am not sure whether there is better way to do this kind of thing though.

[purpleidea]

Apparently sysctl writes to /proc/. A simple strace should probably show exactly where. Apparently this has been ported to kernfs some sort of new kernel fs that proc now sits on instead, and which also supports inotify!

So it would be great if someone could do a little digging and post their results here. Make sure to use a relatively modern kernel.

[sushlala]

Did a little digging around as per your suggestion @purpleidea, looks like ionotify works expected. On one window, I set up io notify watcher on the /proc/sys directory. On the other window, I modified the hostname:

sudo /sbin/sysctl -w kernel.hostname=local
sudo: unable to resolve host local
kernel.hostname = local

which was picked up in the first window:

vagrant@localhost:~$ inotifywait -r -m /proc/sys/
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
...
/proc/sys/kernel/ MODIFY hostname
/proc/sys/kernel/ OPEN hostname
/proc/sys/kernel/ MODIFY hostname
/proc/sys/kernel/ CLOSE_WRITE,CLOSE hostname

uname -a
Linux local 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

How would one submit a patch for this; Is there a similar resource present today?

[purpleidea]

@sushsada Awesome (btw what's this error: sudo: unable to resolve host local)

In any case a sysctl resource would be great... Are there upstream docs or an API where we can determine which path to watch for each sysctl key? Maybe we could ask upstream to to add a --printpath type feature to show us that output so we could figure it out directly?

Lastly, a resource for this would be great. How's your golang? Docs are in: https://github.com/purpleidea/mgmt/blob/master/docs/resource-guide.md resources go in engine/resources/

[sushlala]

That error message- Looks like it's trying to resolve the current hostname:

vagrant@local:~$ cat /proc/sys/kernel/hostname 
oldname
vagrant@local:~$ sudo /sbin/sysctl -w kernel.hostname=newname
sudo: unable to resolve host oldname
kernel.hostname = newname
vagrant@local:~$ echo $?
0

This doesn't seem like it should affect this mgmt resource right? My golang is intermediate, I'd like to pick this item up. My progress might be a little show though.. hope that's okay.

And about mapping from sysctl key to path, looks like a sysctl userspace utility converts .s to /s to look for the corresponding file in /proc/sys. We could do the same: https://github.com/brgl/busybox/blob/abbf17abccbf832365d9acf1c280369ba7d5f8b2/procps/sysctl.c#L283

[purpleidea]

@sushsada

This doesn't seem like it should affect this mgmt resource right?

I wouldn't worry about it for now. I bet it's just sudo being sudo.

My golang is intermediate, I'd like to pick this item up. My progress might be a little show though.. hope that's okay.

Yes of course. We're happy to mentor your patch, and do it at your own pace.

And about mapping from sysctl key to path, looks like a sysctl userspace utility converts .s to /s to look for the corresponding file in /proc/sys

Great! I didn't know it was that straight forward.

Feel free to send an early (even non-compiling) rough draft of your Sysctl resource if you'd like early design feedback. For the inotify side, you should use the existing lib in recwatch as used by the file res.

LMK how it goes.

[sushlala]

Thanks @purpleidea. I'll send out an early review to get your feedback.

[purpleidea]

@sushsada Hey, did you have some early success?

[sushlala]

Here's the sysctl resource I have- first draft, havent proof read it https://gist.github.com/sushsada/8a850ff2b7a5955f46ad3ecd8f6038c8

And my script is :

cat sysctl1.mcl 
sysctl "kernel.hostname" {
  value => "sush.com",
}

However, 'value' is not being picked up:

docker/scripts/exec-development ./mgmt run --tmp-prefix lang --lang sysctl1.mcl

2019-03-11 07:50:12.536873 I | cli: lang: lexing/parsing...
2019-03-11 07:50:12.538339 I | cli: lang: init...
2019-03-11 07:50:12.538381 I | cli: lang: interpolating...
2019-03-11 07:50:12.538498 I | cli: lang: building scope...
2019-03-11 07:50:12.538555 I | cli: lang: running type unification...
2019-03-11 07:50:12.539759 I | run: error: cli parse error: could not unify types: could not determine type for `value` field of `sysctl`

Please share your comments on the code. Also, any pointers on the "cli parse error"? Do I need to add a "mapping" between sysctl.go and the cli layer?

[purpleidea]

@sushsada Cool... Can you send it as a pull request instead? Don't worry, it doesn't mean we have to merge, but it is more easy to send review comments line by line. Also, the automated tests will tell you about some things that need fixing, so I don't need to bug about those =D

As a first simple review, just go through and make sure old copy+pasta comments are removed, and also you'll notice that it's currently based on a slightly older version of the resource API, so if you diff it against something newer, you'll see it has changed slightly. (eg: not Dirty() function, etc)

Thanks!

[purpleidea]

Here are some docs about this https://www.kernel.org/doc/Documentation/sysctl/README