1 |
On Wed, 2006-03-15 at 09:34 -0600, Mikey wrote: |
2 |
> logrotate would be nice for obvious reasons on servers |
3 |
|
4 |
The only package that uses this correctly is squid, so I'd prefer not to |
5 |
add it. |
6 |
|
7 |
> chroot might be nice, as long as it is not too invasive (requires lots of |
8 |
> extra configuration of the packages that utilize it). |
9 |
|
10 |
This would be a bit much. |
11 |
|
12 |
> My main concern is not really what USE flags need to be added as opposed to |
13 |
> what USE flags might need to be removed. In my opinion a generic server |
14 |
> profile needs to be as generic as possible. For example, cups foomatic gpm |
15 |
> and ldap from dev/2006.1/make.defaults should not go into a generic server |
16 |
> profile because in some cases they make significant differences in how |
17 |
> subsequent packages will be configured - samba and apache2 for examples. |
18 |
|
19 |
I would remove gpm, but the others are very unlikely. The purpose here |
20 |
would be to create something that is actually usable as a default. |
21 |
You're more than welcome to customize it yourself, and are expected to |
22 |
do so. Just like how the default USE under the 2006.0 and |
23 |
2006.1/desktop profiles have lots of things some people won't want (both |
24 |
gnome and kde, for example), it is intended to enable support that most |
25 |
people would want, while still remaining somewhat minimal. |
26 |
|
27 |
> None of my servers have pointing devices, gpm is not only useless in this |
28 |
> situation, it introduces additional unnecessary maintenance. mailwrapper |
29 |
> is another example of something that only serves to give me headaches ;) |
30 |
|
31 |
Again, just because none of *your* servers do not have pointing devices |
32 |
does not make it an accurate general statement. My main goal here is to |
33 |
keep all of the desktop USE flags out of the profile. In this case, I |
34 |
can definitely see a use for gpm on a server, unlike gnome or xmms. |
35 |
|
36 |
> I noticed you have STAGE1_USE="nptl nptlonly", does that mean that the CHOST |
37 |
> will need to be changed in stage1 tarballs? |
38 |
|
39 |
Actually, I'm building this currently thinking that glibc 2.4 would be |
40 |
used, which is only nptl. I am not going to be building another set of |
41 |
no-nptl stages on x86. The 2006.0 stages will be considered *it* for |
42 |
building on any non-nptl system without using hardened stages. |
43 |
|
44 |
Of course, any and all of this is likely to change after further |
45 |
discussion with solar and the rest of the hardened/server/infra guys. |
46 |
|
47 |
Honestly, I don't want people to focus on the server profile as much as |
48 |
what really concerns *me* which is the desktop setup that will be used |
49 |
for building the next LiveCD set. |
50 |
|
51 |
-- |
52 |
Chris Gianelloni |
53 |
Release Engineering - Strategic Lead |
54 |
x86 Architecture Team |
55 |
Games - Developer |
56 |
Gentoo Linux |