fixfiles and roles breakdown

[Chris Nolan]

The slack-intro file in the doc folder talks about the fixfiles script
but mentions "Normally, though, you shouldn't need fixfiles." Why? I
see that the permissions on my files are usually wrong and don't match
what the permissions are in the repository. For example /etc/passwd
is 644 in the repository but gets installed on my host as 444. This
makes me think that fixfiles is always necessary. Am I missing
something?

Also, do most people create one role per file installed? This seems a
little extraordinary for managing lots of files. If you don't create
one role per file, do the fixfiles, preinstall, and postinstall
scripts become difficult to manage?

Finally, I'd like to get more involved with slack. I can offer to
help with documentation, coding, evangelism, etc. Who do I talk with
to get involved?

Thanks,
C

[Benjamin Staffin]

If you're creating a role per file, you're probably thinking about
slack the wrong way. I usually make a role for more general things
like "apache" - apt-get install apache2 and friends in the preinstall,
set any special permissions in the fixfiles script (like chowning
.htaccess files appropriately for instance), reload apache's config in
the postinstall. The files in such a role would likely be the config
snippets that go into /etc/apache/conf.d.

Does that help at all?

- Ben

[Chris Nolan]

Ben,

This totally makes sense and I've used a custom tool like slack that
allows you to define a "role" that manages 1-100 files but my question
ties into my other points. How do you ensure proper permissions on
files? Doesn't your fixfiles script for the particular role get
messy? Same question for postinstall and preinstall.

Thanks,
C

[Alan Sundell]

On 6/5/07, Chris Nolan <chris...@gmail.com> wrote:
>
> Ben,
>
> This totally makes sense and I've used a custom tool like slack that
> allows you to define a "role" that manages 1-100 files but my question
> ties into my other points. How do you ensure proper permissions on
> files? Doesn't your fixfiles script for the particular role get
> messy? Same question for postinstall and preinstall.

Most people are fine with the default permissions, which is why they
don't use fixfiles much.

Perhaps you should rewind and explain why you want the installed file
to be mode 644. If you write to the file, your changes will be
overwritten the next time you run slack, no? Generally, the reason to
use slack is you want *not* to be editing files in place :)

As for why slack changes the permissions of the files from what they
are in $SOURCE.... slack is expected to be used in an environment
where the permissions in $SOURCE are relatively meaningless. That's
part of the point -- if you wanted to preserve the permissions from
the $SOURCE directory, you'd just use rsync -a or cp or something and
skip slack altogether :)

Examples:
1) $SOURCE is in your home directory. The files are owned by a
regular user, and have perms that depend on the user's umask and such.
You probably don't want to install them with the same perms.
2) $SOURCE is a checked-out working copy from a source code management
system. SCM systems generally can't be counted upon to store the
complete permissions for a file, so the perms will often depend on who
checked it out and what their umask was.

There is an exception -- slack does preserve the executable bit, since
it's pretty important and most SCM systems can be counted upon to
preserve it, too (presumably, they also recognize its importance).

So the default perms are:
0444 for files
0555 for executable files
0755 for directories

AFAIK, most people are pretty happy with these most of the time, so
they don't need a fixfiles script. They mostly use slack to install
config files and the occasional script, and these all work fine if
they are not writable. Plus, the read-only flag provides a nice "hey,
you shouldn't be editing this here" reminder, helps prevent accidental
local changes, and can raise an error in programs you didn't know
about that might try modifying it locally.

Does that help?

--Alan

[Alan Sundell]

On 6/5/07, Chris Nolan <chris...@gmail.com> wrote:

> Finally, I'd like to get more involved with slack. I can offer to
> help with documentation, coding, evangelism, etc. Who do I talk with
> to get involved?

Seems to me like you're already involved. :)

You've got lots of questions, so feel free to keep asking them. If
anyone's rude to you, I'll smack them down. ;)

At the very least, the answers will show up in the archive for others
to see. Also, maybe out of your questions, you (or someone else) will
come up with some ideas for documentation that will help answer the
questions for others. Documentation is definitely a weak point,
though I guess it's a testament to slack's simplicity that people seem
to pick it up despite that.

Anyway, the rest of this goes for everyone:

Patches, whether to documentation or code, are always welcome. People
can send them to this list, or to me personally if they are shy
(though I am lazy, and more eyeballs is better IMHO) :)

If I weren't so lazy, I'd import my CVS repository into a public SVN
repository like code.google.com, and that would make it easier for
people to browse code and contribute. Someday... :/

As for evangelism, the only guidance I have is this: there are lots of
config management systems out there. They each have their uses, and
I'm not convinced slack is the best (and I wrote the damned thing), so
I wouldn't be too fervent. People should choose the one they think
suits their needs.

In fact, I originally wanted slack to be kind of a "gateway drug" to
"real" config management systems like cfengine. Somehow, however,
that hope never materialized for a lot of my users (including me) -- I
guess they felt slack was good enough for them, or they didn't want to
put in the effort, or whatever. Lazy bastards! ;)

--Alan

PS: Sorry if that was a little incoherent. This wine is *really* good.

[David Lowry]

On Jun 5, 2007, at 10:36 PM, Alan Sundell wrote:
> So the default perms are:
> 0444 for files
> 0555 for executable files
> 0755 for directories
>
> AFAIK, most people are pretty happy with these most of the time, so
> they don't need a fixfiles script. They mostly use slack to install
> config files and the occasional script, and these all work fine if
> they are not writable. Plus, the read-only flag provides a nice "hey,
> you shouldn't be editing this here" reminder, helps prevent accidental
> local changes, and can raise an error in programs you didn't know
> about that might try modifying it locally.

One example I've run across of needing fixfiles would be when you're
distributing files that go in ~/.ssh. ssh is very particular about
permissions of some of the files in this directory. Of course, you
have to use caution when distributing sensitive things like ssh keys
via slack.

[Chris Nolan]

On 6/5/07, Alan Sundell <sun...@gmail.com> wrote:

> You've got lots of questions, so feel free to keep asking them. If
> anyone's rude to you, I'll smack them down. ;)

Thanks. :)

>
> At the very least, the answers will show up in the archive for others
> to see. Also, maybe out of your questions, you (or someone else) will
> come up with some ideas for documentation that will help answer the
> questions for others. Documentation is definitely a weak point,
> though I guess it's a testament to slack's simplicity that people seem
> to pick it up despite that.

I like slack and am enjoying its simplicity. The lack of
documentation and user community concerned me. Knowing the
author/maintainer is active on the mailing list puts me at ease.

> If I weren't so lazy, I'd import my CVS repository into a public SVN
> repository like code.google.com, and that would make it easier for
> people to browse code and contribute. Someday... :/

This would be cool. Do you have an amazon wish list, paypal account,
or a favorite wine that might help with encouragement? ;)

Thanks,
C