Do you happen to have a method that allows the service to be restored on Windows Vista or Seven?

gitweb ist eine schöne Sache – aber nicht immer will man seine Repositories jedermann zugänglich machen. Schön wäre es doch, wenn man die Möglichkeit hätte, auch den Zugriff auf gitweb an eine Anmeldung zu koppeln und so nur für befugte Benutzer zu erl…

1. haven’t messed with the script for a loooong time
2. don’t have a device anymore to test it on

perhaps Tobia (original author) is able to debug this. sorry i can’t help

$ sudo python 8kzenrecover.py -o 52428800 /dev/sda songs test/
Traceback (most recent call last):
File “8kzenrecover.py”, line 210, in
raise “Could not find the root inode”
TypeError: exceptions must be classes or instances, not str

It is a 60gb drive though?

edit: DONE, check post.

while(<FILE>) {

My previous comment seems to have disappeared (or is awaiting moderation). Meanwhile, I have added this item to my documentation, including sample code (untested, but should work), at http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#gitwebauth

Thank you.

Sitaram

Sorry; I live in India and was asleep at the time you came on #git (I assume it was you) and mentioned this.

The way gitolite is designed, doing this boils down to 2 things in your subroutine:

– “do” or “require” a file called ~/.gitolite/conf/gitolite.conf-compiled.pm (this contains just one hash called %repos that was created at “compile” time; more on this below)
– then check if this key exists: $repos{$projectname}{R}{$username} (where username and projectname are as defined in your code above; you still need those code pieces that setup those variables of course).

That’s it! No parsing of any file the way you’re doing now

Gitolite has a slightly different way of dealing with access. Firstly, it’s access config is much, much, more flexible and powerful than the WIndows-ini style that gitosis uses. But the more important thing from your point of view is that parsing the access config is done only once, when you make a change, commit, and push. This “compile” step (as I call it) produces a hash and writes that hash out to a file.

My objective is that the “run time” (loosely speaking, the parts that come into play in deciding whether someone has access) should *not* do any parsing or complex stuff. They only read that hash and check for appropriate keys; that’s it. It has to be as simple as that.

[At work, I might have a need to auditably prove the access controls work as claimed, and it is easier to do that in two steps. In fact the auditors need not worry about the compile at all -- at any time that "...compiled.pm" file mentioned above is all they need to check if they want to be sure, and that contains just one hash, as I said.]

Anyway the end result is that *you* (in your gitweb auth subroutine) need not parse anything. It’s all done for you and sitting in a nice clean perl hash

PS: I wish I could claim credit for anticipating this when I designed gitolite But this is just luck — my design was driven entirely by the auditability issues I described earlier!