On 07/16/2014 03:25 AM, Alex Owen wrote:
> On 16 Jul 2014, at 08:44, Sebastian Luna Valero <[log in to unmask]> wrote:
>
>>
>> Could you please explain why that is not the way to go?
>>
>>
>>
>
> Well in the list below we have
> desktop tweaks which is moot by upstream
> password single user which is moot by upstream
>
> This leaves 2:
> * serial console: which is more cleanly performed by doing a serial console install. As already discussed.
> * no colour ls: this package %post renames /etc/profile.d/colorls.[sh|csh] files so they become inactive.
> This would be better performed in a kickstart %post although see next paragraph.
>
>> What alternatives do you recommend?
>
>
> In my opinion all of these small tweaks are really in the realm of systems administration not distribution packaging.
> In my opinion the best way to administer systems is via a configuration management tool like cfengine3 or puppet  or quattor or $insert_conf_tool_of_choice, failing that use a kickstart file to impose your will on systems.
>
> Helping part-time/amateur system administrators do things in a simple and effective and educational manner is a fantastic goal. I worry that tweek packages do not achieve this aim as they hide “magic” and so are not educational. If the aim is to provide the part-time admin a quick line to add to a kickstart file then equally effective lines added to the kickstart %post rather than the %packges section would achieve the same aim AND be more educational.
>
>
> Also if we accept the need for tweek packages where do we stop? The whole strength of a Linux/Unix/Posix type system is its near infinite configurability. This means there will enevitably disagreements on the distro default configuration. If we are serious about tweaks packages being the way the distro caters for all possible configuration options then we will end up with more tweak packages than there are normal packages. And thus I argue that we should dispense with tweak packages altogether accept the distro has one default configuration that will not satisfy everyone and accept that system configuration is better implemented as a configuration management system rather than a packaging system. Again this is the Unix principal at work: one tool for one job and do it well.
>
> Anyway those are my thoughts.
>
>
> Alex Owen
>

I think this might be a bit overblown.  I'm probably what you call a 
part-time admin, but not in the same frame as you are portraying.  In an 
ideal world, you would have something like puppet to control a local 
network of machines.  In my use case, I roll a custom install DVD that 
gets installed "at the factory" and shipped out to customers around the 
globe.  Some with internet access, some not.  I also have more than 1 
person doing the installation and configuration of those machines.

The easiest way, for me, was to roll custom packages to insert into my 
install image and add to the package list.  This allows me to document 
(via the src rpm) all of the changes and easily keep revision 
information on changes to those packages.  Adding a bunch of random 
stuff to the kickstart %post can quickly get messy/unruly and there is 
no mechanism for revision history (especially post-install).  I also 
found it somewhat difficult to get files onto the installed system via 
the %post scripts.  Much easier to rpm them in.  I do use %post for some 
things as well.

Providing the tweak packages does not negatively impact those that want 
to stick with TUV setup or use something like puppet.  They can simply 
choose not to install the packages.  SL has provided these hand full of 
tweaks for as long as I can remember and I don't think they have ever 
gotten out of hand.

In the end, if they go away, I will just roll my own so it's no big deal.

Different strokes for different folks...

-Mark


>> Best regards,
>> Sebastian.
>>
>>
>>
>> 2014-07-16 8:24 GMT+01:00 Alex Owen <[log in to unmask]>:
>> On 9 Jul 2014, at 18:58, Orion Poplawski <[log in to unmask]> wrote:
>>
>>> On 07/07/2014 10:07 AM, Pat Riehecky wrote:
>>>> For SL6 we include the following 'tweak' rpms:
>>>>
>>>> SL_desktop_tweaks
>>>> SL_enable_serialconsole-1152
>>>> SL_enable_serialconsole-192
>>>> SL_enable_serialconsole-384
>>>> SL_enable_serialconsole
>>>> SL_enable_serialconsole-96
>>>> SL_no_colorls
>>>> SL_password_for_singleuser
>>>>
>>>>
>>>> The 'SL_desktop_tweaks' added a terminal to the menu bar, in SL7 this is
>>>> already done by upstream.
>>>>
>>>> The 'SL_password_for_singleuser' required the root password for single user
>>>> mode, in SL7 this is already done by upstream.
>>>>
>>>> This leaves 'SL_enable_serialconsole' and 'SL_no_colorls'.
>>>>
>>>>
>>>> With SL7 the terminal seems to be very good a detecting support for the ASCII
>>>> controls which set the colors.  Is this still something the community wants?
>>>>
>>>>
>>>> With SL7 the serial consoles are very easy to setup.  Simply add:
>>>>
>>>> GRUB_SERIAL_COMMAND='serial --speed=9600 --unit=0'
>>>> GRUB_TERMINAL_OUTPUT="$GRUB_TERMINAL_OUTPUT serial"
>>>> GRUB_TERMINAL_INPUT="$GRUB_TERMINAL_INPUT serial"
>>>> GRUB_TERMINAL="$GRUB_TERMINAL serial"
>>>> GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX console=tty0 console=/dev/ttyS0,9600"
>>>>
>>>> to /etc/sysconfig/grub
>>>>
>>>> Anaconda (the installer) does this for you automatically if the serial options
>>>> are set with kickstart.
>>>>
>>>> What are the various feelings here?  Make these rpms, don't make them?
>>>>
>>>> Pat
>>>>
>>>>
>>>
>>> Personally, never heard of them, and generally configuration by rpm installation seems like not the right way to go.  But I'm a small user…
>>>
>>
>> I concur that configuration by tweak packages is not a clean way to configure machines.
>> For what it is worth Debian Policy prohibits one package from changing the configuration files of another package.
>> The sound reasoning behind the Debain Policy would, in my opinion, also apply to Scientific Linux.
>>
>> Regards
>> Alex Owen
>>
>> —
>> https://github.com/raowen/conlog - Open Source IPMI Console Server and Logger
>>