A few things:
- The git repository tracking CVS works according to spec now (tracks pikefarm and trails it in less than 4 minutes at anytime for 7.8 and 7.9).
- There are two repositories:
git clone git://pike-git.lysator.liu.se/pike git clone git://pike-git.lysator.liu.se/pikex
The first repository contains only the official CVS branches. The second repository contains the official CVS branches *and* any experimental branches developers wish to advertise. As an example of one of the experimental branches, I created a branch called "testing" which is intended to be the last know stable snapshot of the development branch (7.9).
- As of now I would like to invite developers to ask for push/commit access to the pikex repository, in order to test and play around with committing directly to centralise git branches. The branches in pikex will be partly/selectively protected, depending on who wants to commit. There basically are several levels of protection: - People which I don't have the public key from cannot push at all. - For those that are able to push, the following restrictions will (currently) be enforced by the repository: + The official branches 0.5 ... 7.8 nt-tools extra_tests are protected and cannot be pushed into (currently). + Some branches are restricted to mere additions (regular commits). + Some branches cannot be committed to by all developers. + Some branches have no restrictions (i.e. can be created/removed or can even be destructively altered).
- If we ever move to git as the leading central repository, then the central repository will become pushable as well, but with severe restrictions (only regular commits, nothing destructive, no branch creation).
- In order to start granting access to pikex, I need public keys of developers.
After you've handed me the keys, pushing into the repository should become possible using a URL like:
git-pike@pike-git.lysator.liu.se:pikex
which actually is a shorthand for:
ssh://git-pike@pike-git.lysator.liu.se/~/pikex
On Sat, Aug 16, 2008 at 12:36:30PM +0200, Stephen R. van den Berg wrote:
- In order to start granting access to pikex, I need public keys of developers.
is it enough to point to the public keys already stored on pelix? you mean ssh keys right? if yes, please count me in.
greetings, martin.
Martin B?hr wrote:
On Sat, Aug 16, 2008 at 12:36:30PM +0200, Stephen R. van den Berg wrote:
- In order to start granting access to pikex, I need public keys of developers.
is it enough to point to the public keys already stored on pelix? you mean ssh keys right? if yes, please count me in.
Yes, I mean ssh keys. I do not have access to the keys at pelix, and since sometimes there are multiple keys at pelix for any one developer, some of the keys might be outdated, I'd simply ask anyone interested to mail me the keys (could be multiple) they wish to use.
I'd suggest that those of you that want access log in to pelix and put the public key you want to use in a file that is globally readable and then tell srb about it.
Peter Bortas @ Pike developers forum wrote:
I'd suggest that those of you that want access log in to pelix and put the public key you want to use in a file that is globally readable and then tell srb about it.
Well, I looked on pelix, and in order to keep things simple, simply make your .ssh/authorized_keys file on pelix readable for me (srb@pelix), either through group "pike" or world readable. And I'll fetch the keys from there, might even run a daily script to keep things synced or something.
I currently copied the public ssh keys on pelix of:
mbaehr mast distmaker
So they have (regulated) commit access on the pikex git repository as of now (try and break it, or simply use it to play around with git pushes or publish any of your development branches).
You can also try and push into the pike git repository, it should simply refuse (even if it were to allow it, no harm done, nothing you do is irreparable).
Well, I looked on pelix, and in order to keep things simple, simply make your .ssh/authorized_keys file on pelix readable for me (srb@pelix), either through group "pike" or world readable.
This is a bad idea, as it will make the keys stop working on pelix (sshd cares about the protection bits). Better to copy the keys to a group/world-readable file outside the .ssh directory.
they are public keys. ssh does not complain if those are world readable. i didn't actually change any permissions, my authorized_keys file has been world readable since account creation
greetings, martin.
It doesn't complain for me on pelix, and my .ssh directory is world readable (of course, since Stephen got my public keys).
Ok, then we have an old and more leniant version of sshd installed on pelix. Carry on. :-)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Ok, then we have an old and more leniant version of sshd installed on pelix. Carry on. :-)
The openssh-server on Debian testing doesn't care either (and I really don't see why it should complain, so maybe they complained before, but saw the error in their ways and fixed it in newer versions?).
It might be that it's only Solaris' own sshd which cares so much about this. Pelix seems to be running an OpenSSH sshd.
Old OpenSSH ones cared. At least in some configurations. Redhat 5 locks out users if the directory is world readable.
Then let me take the opportunity to also inform that the SVN reposiotory at svn+ssh://pike.ida.liu.se/pike/data/repos/Pike is updated to handle the 7.8 rename, and contains all commits to all branches up to this Thursday evening.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg