Kernel compiles and you
Michał Górny posted on Wed, 04 Jul 2012 22:38:50 +0200 as excerpted:
> On Wed, 4 Jul 2012 20:06:58 +0200 Tobias Klausmann <klausman@gentoo.org>
> wrote:
>
>> On Wed, 04 Jul 2012, Michał Górny wrote:
>> > There's a very simple yet custom solution I'm using. Shortly saying:
>> > checkout the kernel git to /usr/src/linux and chown to your user. As
>> > far as it goes, it's superior to having kernel sources installed by
>> > ebuilds.
>> >
>> > I just have to remember to do 'git fetch' from time to time and 'git
>> > merge' whenever a new version is tagged.
>>
>> It is also beyond the package manager's control. That means users who
>> want to just configure their kernel (and run point releases otherwise)
>> have to actively check for new tags/versions.
>
> True. I think that's the direction I should look into improving.
>
>> Aside from that the git tree is not exactly lightweight: my current 2.6
>> checkout weighs in at 1.4G whereas the unpacked tar is 512M.
>
> Well, that's the other problem. On the other hand, you usually have to
> have that 1G free anyway unless you intend to manually unmerge the
> previous *-sources before installing the new one. And the time needed to
> do that... git is so much faster.
I'll second the git being faster bit. What's especially nice about it is
that checking out and building any arbitrary tag (release or rc), or for
that matter, doing a bisect down to an individual commit, if you're
trying to track down some issue or other, is really easy. [1]
But the main reason for this reply is to add this idea:
Here, I have my regular user, and I have my admin-hat user. My regular
user has sudo locked down quite strictly, with a password required for
anything not specific parameter locked, etc. But, the one thing the
regular usr CAN do, is sudo (with password) to the admin user.
Additionally, my regular user isn't in the portage, wheel, etc, groups
either (and polkit is generally locked down for it as well), so it really
is quite privilege-locked, EXCEPT that it can sudo to admin.
The admin user then has unrestricted passwordless sudo access. Basically
root, except that I can type the command unprivileged first, then when
for instance the rm gives me the expected permissions error, I can see
that it's what I did indeed intend to rm, and arrow-up, home, sudo in
front, to actually do it.
The admin user is then what I use to git pull and build the kernel, so
that's the only user (other than root) with write access to the kernel
sources. My normal user doesn't have that access, thus avoiding the
normal-user-writable security issue mentioned in your (klausman's) blog.
Since that admin user then has unrestricted passwordless sudo, sudoing
(from that admin user) to root for the actual install is trivial.
Meanwhile, I actually have a set of kernel maintenance helper scripts
that I use to update, configure (either oldconfig for the update or just
to change something...), build and install the kernel. They're not ready
for use by the general public yet, but they're a reasonable start,
including a configuration file for most stuff one might want to change
(where the kernel dir is located, where the output dir is located so as
to keep the sources dir itself clean if so desired, whether to auto-
mount /boot for installation, etc). There's even provision for
automatically applying patches from a user patches dir! =:^)
Since I've been running a git kernel for several years now, the git-
kernel scripts are current, but I did start on the scripts back when I
was still using tarballs, so there's scripts that automate most of that,
as well, tho they're a bit stale now as I've not actually run/tested them
in a couple years (but I did try to update them for the 3.0 kernel, etc).
If you'd like, I can email them. As I said, they're not really fit for
public consumption yet, but it's a reasonable start including a config
file, and I use it for maintaining my systems (both x86 and amd64,
separate output dirs based on the bash ARCH variable) here, with a
maturity and development over several years, so if you're interested in
/making/ them fit for public consumption, it'd certainly save quite some
days work over starting from scratch.
Obviously I'm running/testing the scripts as a gentoo user, but other
than perhaps some of the config file comments, there's not a whole lot
specific to gentoo about 'em.
---
[1] I routinely run live-git kernels, but don't like to run anything
before rc1 until some days later, just in case. So when a release comes
out, I'll often update a couple days into the new cycle, and then simply
checkout and build the release tag. Then sometime after rc1 or rc2, I
update again, and test from there. I figure if I need to bisect
anything, news of any too drastic data-eating bugs pre-rc1 should be
available, and I can then bisect back into the previously blackout period
with a bit more confidence.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
|
