Gitolite3 on pkgs01.stg
by Pierre-Yves Chibon
Dear all,
This morning Mathieu (bochecha) and I spent some time trying to get gitolite3
work on our pkgs01.stg.
This is an overview of the situation.
By design gitolite is meant to be installed with a dedicated user. Everyone uses
that user. gitolite then maps the public ssh key to its user database and its
configuration file to handle who is allowed to do what on which git repo.
Our setup is quite different from this. We have a single configuration file at
/etc/gitolite/conf/gitolite.conf that contains all the information about who
is allowed to do what on which git repos. In addition we have a single
/etc/gitolite/gitolite.rc configuration file that specifies to gitolite where
are the git repositories located.
Each user has then an account on the machine but by default no shell access.
The access is restricted via ssh with in ~/.ssh/authorized_keys the instructions:
`command="/usr/bin/gl-auth-command"` (people with shell access have a different
command).
That commands combines the info from /etc/gitolite/gitolite.rc and
/etc/gitolite/conf/gitolite.conf and allow or deny the access/action.
Now gitolite3 has changed quite a bit compared to our setup.
Basically, gitolite3 expects the gitolite.rc file to be at ~/.gitolite.rc and
the repositories to be at ~/repositories. Having symlink to these locations
are fine, but they should be there.
What we can do also is play on the $HOME variable.
In pkgs01.stg we kept the configurations files (gitolite.conf and gitolite.rc)
in /etc/gitolite as before, but we created a couple of symlink in /srv/git/
.gitolite -> /etc/gitolite/
repositories -> /srv/git/rpms/
The idea is to be able to set HOME=/srv/git and run the gitolite command.
This way we managed to get the genacls.sh script working. It is the script
that generates the gitolite.conf file based on the pkgdb information and compile
that configuration file so that gitolite can use it.
gitolite3 also changes the command in the ~/.ssh/authorized_keys file to:
command="/usr/share/gitolite3/gitolite-shell user"
That command is set in the sources in `src/triggers/post-compile/ssh-authkeys`
and put in the file by (I believe) `gitolite compile` that is ran by genacls.sh.
In order to test, I (manually) changed Mathieu's authorized_keys to look like:
command="HOME=/srv/git/ /usr/share/gitolite3/gitolite-shell user"
We then tried to get Mathieu to clone a repo and we found out:
- the ~/.gitolite folder, that gitolite3 requires, needs to have a `logs/`
subfolder, and that folder needs to be accessible read and write to everyone
so `chmod 777 -R /srv/git/.gitolite/logs` (ie: chmod 777 /etc/gitolite/logs
since it's a symlink)
- the /etc/gitolite/conf/gitolite.conf-compiled.pm needs to be readable by
everyone since it's the file gitolite uses to see who can do what on which
repo
so `chmod o+r conf/gitolite.conf-compiled.pm
- Mathieu was finally able to clone and push in a repo he has access to and
could not on the kernel repo (as supposed to since he does not have commit
there), but the error returned is just plain ugly
So to conclude:
- we managed to get it to work
- its needs chmod 777 on /srv/git/.gitolite/logs
- its needs chmod o+r on conf/gitolite.conf-compiled.pm (and that after each
time the file is generated)
- we need to find a way to fix the command in the user's ~/.ssh/authorized_keys
so that they specify the HOME variable to use when running the gitolite
command
-> Might very well require to patch gitolite itself for this (and thus keep
the patch in our package ad vitam aeternam)
That being said, I believe our options are:
1) Talk with upstream, in the past I believe he was quite reactive and willing
to help us. We are the largest public deployment of gitolite maybe he'll
still be willing to help us
to discuss:
- setting HOME in the authorized_keys
- writing logs
- accessing gitolite.conf-compiled.pm
2) Stick with gitolite2
-> We need to find out how easy it is to maintain it on epel7 and we need
someone willing to maintain it (knowing that it's perl)
-> Upstream said gitolite2 is still maintain wrt security fixes but I guess
only for some time
3) Move to the model gitolite relies on (1 specific gitolite user everyone
accesses the repo through).
+ No more need to create account on the machine for each and every packager
+ Inline with gitolite's design
- Breaking all existing git clone around (as the push/pull urls change)
--> URLs change could be handled at the fedpkg level
+ We are already forcing an update of fedpkg to our packager with the change
from md5 to sha for the lookaside cache, so we could couple both change in
the same update and preventing forcing two fedpkg updates.
- Huge number of keys to handle for that user
? Performance impact of this number of users?
? Dennis mentionned logging at the meeting yesterday, but it looks like
gitolite does provide logging itself
4) Move away from gitolite.
I did not check what else would be available/suitable for us, so no ideas
there. Suggestions welcome I guess :)
I think that covers most if not all our findings.
Questions and suggestions welcome :)
Pierre and Mathieu
8 years, 9 months
Something is polluting lockbox01 /
by Stephen John Smoogen
So I feel bad.. I didn't see this til today and its been going on for a
while. Some script is putting a lot of file entries in / versus where-ever
it is supposed to do so. The entries will be <something>.retry
-rw-r--r--. 1 root root 36 Sep 16 04:28
fed-cloud09.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 68 Jul 24 07:54 fedimg.retry
-rw-r--r--. 1 root root 106 Jun 17 04:29 fedoauth.retry
-rw-r--r--. 1 root root 16 Aug 19 04:09 fedocal.dev.fedoraproject.org.retry
-rw-r--r--. 1 root root 103 Jun 17 04:26 fedocal.retry
-rw-r--r--. 1 root root 37 Jul 27 05:53 gallery.retry
-rw-r--r--. 1 root root 43 Jun 17 04:11 github2fedmsg.retry
-rw-r--r--. 1 root root 28 Sep 16 04:23 hrf.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 16 Aug 31 11:44 jenkins-cloud.retry
-rw-r--r--. 1 root root 36 Jul 2 14:05 kerneltest.retry
-rw-r--r--. 1 root root 50 Aug 16 07:14 keyserver.retry
-rw-r--r--. 1 root root 34 Jun 17 04:30 koji-hub.retry
-rw-r--r--. 1 root root 32 Aug 26 04:18
koschei.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 34 Aug 19 04:07
lists-dev.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 36 Sep 16 08:21 lockbox.retry
-rw-r--r--. 1 root root 29 Jul 23 04:04 logserver.retry
-rw-r--r--. 1 root root 16 Aug 19 04:08
logstash-dev.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 66 Jul 1 04:11 mailman.retry
-rw-r--r--. 1 root root 41 Sep 3 10:39 mirrorlist.retry
-rw-r--r--. 1 root root 29 Jul 10 05:02 nagios_phx2.retry
-rw-r--r--. 1 root root 24 Sep 9 07:45 noc.retry
-rw-r--r--. 1 root root 84 Jul 18 07:02 notifs-backend.retry
-rw-r--r--. 1 root root 152 Jun 17 04:30 notifs-web.retry
-rw-r--r--. 1 root root 144 Jun 17 04:29 nuancier.retry
-rw-r--r--. 1 root root 106 Aug 2 09:57 packages.retry
-rw-r--r--. 1 root root 97 Jul 23 07:26 paste.retry
-rw-r--r--. 1 root root 97 Jun 17 04:30 pkgdb.retry
-rw-r--r--. 1 root root 68 Jun 17 04:26 postgresl-server.retry
-rw-r--r--. 1 root root 33 Aug 17 07:47 qadevel-stg.retry
-rw-r--r--. 1 root root 32 Jun 17 04:26 releng.retry
-rw-r--r--. 1 root root 37 Aug 7 11:00 resultsdb-dev.retry
-rw-r--r--. 1 root root 33 Sep 16 07:19 resultsdb-prod.retry
-rw-r--r--. 1 root root 37 Sep 4 05:01 resultsdb-stg.retry
-rw-r--r--. 1 root root 16 Aug 19 04:06
shogun-ca.cloud.fedoraproject.org.retry
-rw-r--r--. 1 root root 34 Jul 9 07:08 smtp-mm.retry
-rw-r--r--. 1 root root 76 Jul 18 06:57 summershum.retry
-rw-r--r--. 1 root root 72 Aug 7 09:48 sundries.retry
-rw-r--r--. 1 root root 100 Jun 17 04:41 tagger.retry
-rw-r--r--. 1 root root 160 Jul 23 05:30 taskotron-dev-clients.retry
-rw-r--r--. 1 root root 37 Jul 23 09:54 taskotron-dev.retry
-rw-r--r--. 1 root root 160 Jul 23 04:34 taskotron-prod-clients.retry
-rw-r--r--. 1 root root 33 Sep 16 07:27 taskotron-prod.retry
-rw-r--r--. 1 root root 40 Sep 12 05:21 taskotron-stg-clients.retry
-rw-r--r--. 1 root root 37 Jul 23 05:07 taskotron-stg.retry
-rw-r--r--. 1 root root 37 Jun 19 14:13 taskotron.retry
-rw-r--r--. 1 root root 34 Jul 1 07:20 unbound.retry
-rw-r--r--. 1 root root 66 Jun 17 04:27 value.retry
-rw-r--r--. 1 root root 37 Sep 16 13:19 virthost.retry
-rw-r--r--. 1 root root 30 Jul 24 04:40 wiki.retry
Anyone know what this is?
--
Stephen J Smoogen.
8 years, 11 months
Python/Django developers needed: Ask Fedora
by Rahul Sundaram
Hi
Ask Fedora (http://ask.fedoraproject.org) uses Askbot which is a Django
based web application. We need a few developers to implement some bug
fixes and features for askbot and while upstream developers are active,
our requirements are pretty high. So if anyone here wants to help out,
please ping me offlist and I can describe the things we would like to see
implemented quickly. Some of them shouldn't take much of your time if you
are a Django developer and would help our moderators and users quite a lot.
Thanks,
Rahul
8 years, 12 months
Plan for tomorrow's Fedora Infrastructure meeting (2014-08-21)
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2014-08-21 at 18:00 UTC in #fedora-meeting on the freenode network.
Suggested topics:
#topic New folks introductions and Apprentice tasks.
If any new folks want to give a quick one line bio or any apprentices
would like to ask general questions, they can do so in this part of the
meeting. Don't be shy!
#topic Applications status / discussion
Check in on status of our applications: pkgdb, fas, bodhi, koji,
community, voting, tagger, packager, dpsearch, etc.
If there's new releases, bugs we need to work around or things to note.
#topic Sysadmin status / discussion
Here we talk about sysadmin related happenings from the previous week,
or things that are upcoming.
#topic nagios/alerts recap
Here we go over the last weeks alerts and see if we can find ways to
make it so they don't happen again.
#topic Upcoming Tasks/Items
https://apps.fedoraproject.org/calendar/list/infrastructure/
#topic Open Floor
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings
Thanks
kevin
8 years, 12 months
people ssh Banner
by Kevin Fenzi
So, we have had a number of folks recently come and tell us they are
having trouble logging into fedorapeople.org and after troubleshooting
we find that they are not in any non cla groups, so don't even have an
account there.
I've tried to stress the requirements on the people page on the wiki,
but I think some people are learning about it word of mouth and aren't
finding out the requirements for accounts.
To help with this I setup a ssh Banner the other day.
So, every connection gets a short message:
---snip---
This system is for Fedora Contributors only!
You must be in at least one non cla group to have access.
See: https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org
---snip---
There's however a few problems with this and I have reverted it for
now. Problems include:
* Annoys people who do have accounts.
* Breaks scripts that look for just specific content
* Tells attackers if someone has an account or not.
So we could:
* Just keep it disabled and try and get people to read docs
* Re-enable it but make the message 1 line to be less anoying.
* Some other clever solution.
kevin
8 years, 12 months
Updated Atomic alpha w/Bash update(s)?
by Joe Brockmeier
Hi all,
It occurs to me that the bash update isn't going to be available for the
Atomic image(s) since the users can't install new packages.
What do we need to do to get new images spun up and get a new tree for
people to grab with rpm-ostree update?
My understanding is this is manual now, how much lifting do we have yet
to do to make this automatic?
Thanks,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years
fedimg ansible files, take 2
by David Gay
Hey squad,
First, apologies to the list, since I sent the initial draft of this patch to the internal Red Hat fedora-eng list when it should have gone here. My bad.
Fixed up the Fedimg ansible files as per threebean's suggestions and gracious assistance. The patch is attached. If a pair or two of eyes wouldn't mind checking it out, that'd be swell. Got the +1 from threebean in IRC, at least at a glance.
I'm working out some boot issues with a couple image types in EC2 right now, so if this is plugged in as things are now, some image uploads will invariably fail, so perhaps we want to wait on launching this until I have better results with AMI booting.
If things look good, I can send threebean the creds/variables that would be needed for the config setup, since I'm not in sysadmin-main.
Thanks!
-- oddshocks
9 years
Plan for tomorrow's Fedora Infrastructure meeting (2014-09-25)
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2014-09-25 at 18:00 UTC in #fedora-meeting on the freenode network.
Suggested topics:
#topic New folks introductions and Apprentice tasks.
If any new folks want to give a quick one line bio or any apprentices
would like to ask general questions, they can do so in this part of the
meeting. Don't be shy!
#topic Freeze reminder
#topic Applications status / discussion
Check in on status of our applications: pkgdb, fas, bodhi, koji,
community, voting, tagger, packager, dpsearch, etc.
If there's new releases, bugs we need to work around or things to note.
#topic Sysadmin status / discussion
Here we talk about sysadmin related happenings from the previous week,
or things that are upcoming.
#topic nagios/alerts recap
Here we go over the last weeks alerts and see if we can find ways to
make it so they don't happen again.
#topic Upcoming Tasks/Items
https://apps.fedoraproject.org/calendar/list/infrastructure/
#topic Open Floor
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings
Thanks
kevin
9 years
Atomic / Fedora Infrastructure Meeting 23 September 2014
by Joe Brockmeier
A bit late getting these out, sorry about that!
===============
#atomic Meeting
===============
Meeting started by jzb at 18:02:06 UTC. The full logs are available at
http://meetbot.fedoraproject.org/atomic/2014-09-23/atomic.2014-09-23-18.0...
.
Meeting summary
---------------
* dgilmore is short on time today due to F21 release tasks leftover,
will have to defer to next week (stickster, 18:14:33)
* Compose scripts (stickster, 18:16:17)
* Fedora mainline compose scripts don't have the capability to be run
locally; tools are the same, but configuration may not allow someone
to actually make images (stickster, 18:20:16)
* highest priority goal is a cloud image that boots in at least KVM
and OpenStack and an ostree repo with a mirrorlist that we can pull
updates from (stickster, 18:25:43)
* ACTION: jzb figure out who's got the ball with mirrormanager. (jzb,
18:39:24)
* ACTION: oddshocks will look into Mirrormanager changes and report
back (jzb, 18:45:48)
* jzb thanks oddshocks profusely (jzb, 18:45:58)
* ACTION: oddshocks to send note to cloud(a)lists.fedoraproject.org when
AMIs are ready (jzb, 18:50:32)
Meeting ended at 18:51:34 UTC.
Action Items
------------
* jzb figure out who's got the ball with mirrormanager.
* oddshocks will look into Mirrormanager changes and report back
* oddshocks to send note to cloud(a)lists.fedoraproject.org when AMIs are
ready
Action Items, by person
-----------------------
* jzb
* jzb figure out who's got the ball with mirrormanager.
* oddshocks
* oddshocks will look into Mirrormanager changes and report back
* oddshocks to send note to cloud(a)lists.fedoraproject.org when AMIs
are ready
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (42)
* walters (29)
* jzb (27)
* dgilmore (22)
* oddshocks (15)
* smooge (6)
* geppetto (5)
* centbot (4)
* zodbot (4)
* jbrooks (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years