Request for a sketch to allow me to list what packages should be on a system

[atsaloli]

I'd like to request a sketch please to allow me to list what packages should be on a system. I want all my favorite tools there (vim, tmux, git, irssi, etc.)

To elaborate somewhat, when I am on a new CentOS system that is not under configuration management control (but ought to be), one of the first things I'll run is "sudo yum -y install git" etc to install git. I don't have to specify the version or the architecture -- the package manager figures it out -- I'm usually happy with the default.

if I'm on Ubuntu, I run "sudo apt-get install -y git" and it does the same thing.

I just want to have a list of my favorite packages BY NAME and have CFEngine install them.

I DON'T want to be pestered with the architecture details. I understand CFEngine is flexible and configurable so it can install Debian packages on Red Hat or whatever, but what I really want, as a simple sysadmin, is some built-in smarts: if we're on Ubuntu, then use the default package manager that ships with the OS.

We're trying to make CFEngine higher level and easier to use, right? Well, let's say I want git. That's all I should have to tell CFEngine. :) That's all I have to tell it at the command line. (well that and "apt-get".) I don't mind if the config file I use (my interface to this sketch) has two sections, Ubuntu and Red Hat: the package names sometimes differ, after all (e.g. "httpd" on Red Hat and "apache2" on Debian). But I'm also willing to use two separate config files or two separate lists. The driving point here is simplicity -- I just want to give a list of names of packages to install on Ubuntu or Debian systems and have CFEngine install them.

[atsaloli]

Brian Bennett suggested this functionality should be package manager neutral.

[tzz]

You can currently do:

vars:
"mine" slist => { "git", ... };
packages:
 "$(mine)" package_method => generic; # or something you can define based on the stdlib generic

Is this too complicated? Or are you looking for something even more general? Or are you asking for a data-driven sketch that takes a slist from JSON and just does the package method invocation above?

In the last case there's one big issue. You can't specify an arbitrary package method by a variable, like you can specify a bundle by a variable. So you'd be limited to a hard-coded selection of package methods, which is not very useful.

What do you think? Am I understanding you correctly?

[zzamboni]

I think the value for something like this could be to allow you to abstract away the actual package names, and have them coded into the sketch (like the paths bundle in the stdlib).

For example, Apache's package is "httpd" in some Linux'es, "apache2" in others, and maybe some other name in other places. Git is "git" in some, "git-core" in others, etc. With a sketch like this you could have "apache" map to the correct package name (or names! maybe you want "git" to expand to "git-core", "git-man" and "git-doc"), same with "git". Of course you'd still need to know the list of names supported by the sketch, but that might still be simpler than trying to remember and encode the actual package names for all the OSs you want to support.

Thoughts?

[tzz]

Right, but you'd have to always use the "generic" (or some hard-coded list) package manager. I don't know how to work around that in today's agent... we could ask for the package manager to be specified by a variable perhaps? Then the user could define it themselves?

[nickanderson]

I was just thinking a simple csv for favorites that you feed to the sketch.

Context expression, package name

Still using the generic package method.

Ted Zlatanov [email protected] wrote:

Right, but you'd have to always use the "generic" (or some hard-coded
list) package manager. I don't know how to work around that in today's
agent... we could ask for the package manager to be specified by a
variable perhaps? Then the user could define it themselves?

---

Reply to this email directly or view it on GitHub:
#273 (comment)

Sent from Kaiten Mail. Please excuse my brevity.

[zzamboni]

Why? You could have per-supported-OS sections, both for the variable assignments (i.e. the generic name to package name mappings) and the corresponding package methods, invoking the OS-specific package methods. Much like what is done in the standard_services() bundle today.

On Apr 25, 2013, at 3:27 PM, Ted Zlatanov [email protected] wrote:

Right, but you'd have to always use the "generic" (or some hard-coded list) package manager. I don't know how to work around that in today's agent... we could ask for the package manager to be specified by a variable perhaps? Then the user could define it themselves?

—
Reply to this email directly or view it on GitHub.

[tzz]

We'd have to supply a special generic package method, which is useless, or use the stdlib generic package method, which is not suitable for most users. Really what's needed is a way for the user to supply the generic package method they want. For instance @atsaloli wants a package method that uses "sudo apt-get" unlike the ones in the stdlib. How would you provide that generically if he can't write it himself?

[zzamboni]

For this kind of generic extensibility, then I agree it's hard to do at the moment. But we could have the sketch with hard-coded proper values for a number of distributions and their most common package managers, and it could still be useful, just like the existing paths() or standard_services() bundles.

On Apr 25, 2013, at 6:15 PM, Ted Zlatanov [email protected] wrote:

We'd have to supply a special generic package method, which is useless, or use the stdlib generic package method, which is not suitable for most users. Really what's needed is a way for the user to supply the generic package method they want. For instance @atsaloli wants a package method that uses "sudo apt-get" unlike the ones in the stdlib. How would you provide that generically if he can't write it himself?

—
Reply to this email directly or view it on GitHub.

[tzz]

We'd be reinventing the generic package method and as I said, it still wouldn't cover the @atsaloli use case. I don't see how it's useful.

Why not just take a list of packages and call a shell command on them? That's much closer to what @atsaloli is trying to do.

[tzz]

I think the Blueprint integration at devstructure/blueprint#138 (and implemented on the DC side with #299) is what you're looking for. If you like it, vote for that pull request or tell me what to fix.

Blueprint will generate the list of packages with versions for many popular package managers. It will also assemble all the files worth preserving, services you want to keep, etc.

The CFE3 frontend I wrote is pretty simple to use and generates a DC sketch you can install. So you can simply take the written sketch and modify it to add/remove packages... or simply use what's been discovered already.

@atsaloli let me know if that's close to what you wanted, and if not, how it can be done better.

[tzz]

ping @atsaloli

[nickanderson]

@tzz can you screen cast it?
On May 15, 2013 9:22 AM, "Ted Zlatanov" [email protected] wrote:

I think the Blueprint integration at devstructure/blueprint#138devstructure/blueprint#138 implemented on the DC side with
#299 #299) is what
you're looking for. If you like it, vote for that pull request or tell me
what to fix.

Blueprint will generate the list of packages with versions for many
popular package managers. It will also assemble all the files worth
preserving, services you want to keep, etc.

The CFE3 frontend I wrote is pretty simple to use and generates a DC
sketch you can install. So you can simply take the written sketch and
modify it to add/remove packages... or simply use what's been discovered
already.

@atsaloli https://github.com/atsaloli let me know if that's close to
what you wanted, and if not, how it can be done better.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/273#issuecomment-17941397
.

[atsaloli]

Sorry, haven't had a chance to look at this yet. I know it's in my queue.
The documentation review work is keeping me busy.

Yours fondly,
Aleksey

On Thu, May 30, 2013 at 10:20 AM, Ted Zlatanov [email protected]:

ping @atsaloli https://github.com/atsaloli

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/273#issuecomment-18695405
.

CFEngine Training:
Irvine, California, October 14 - 17. http://cf3irvine.eventbrite.com/