On 16/02/16 02:13, Carsten Haitzler wrote: > On Mon, 15 Feb 2016 11:16:52 +0000 Tom Hacohen <t...@osg.samsung.com> said: > >> On 10/02/16 17:31, Carsten Haitzler wrote: >>> On Wed, 10 Feb 2016 09:31:26 +0000 Tom Hacohen <t...@osg.samsung.com> said: >>> >>>> Hey, >>>> >>>> I reverted this patch. This patch is absolutely wrong, this is not the >>>> right place for it. Furthermore, for whatever reason, this patch broke >>>> key sync, so not only that it's wrong, but it didn't fix anything. >>>> >>>> I currently have two keys for apache, neither of them is this one. >>>> Please just make sure you know what the right key is, and that beber >>>> agrees (because you guys keep on messing up the keys, he's removing >>>> keys, you are adding them in the wrong place). >>>> >>>> Once you are in agreement, send me or him the key, and we'll update it >>>> accordingly. >>>> >>>> Again, this commit DID NOT fix anything, because it was never applied. >>>> So if everything works, it's because of what I did a while back, if it >>>> doesn't, let me know and we can fix it. Just please stop employing this >>>> hack. >>> >>> what did you do to make key sync STOP working with an apache user? it worked >>> when i originally set up dokuwiki. you must have done something to make it >>> explicitly not work. i kept asking you how to update the dev keys and you >>> didnt know how. now you say you did something? what? where? >> >> Huh? when did I ever say I didn't know how. Of course I know how to >> update the keys, I deal with gitolite all the time. I have no idea what > > oh sorry - it was stefan i was talking to: > > Feb 05 16:52:40 <raster> so how do i force git to update its devs? > Feb 05 16:52:45 <raster> cgit/whatever? > Feb 05 16:54:36 <stefan_schmidt> hmm? > Feb 05 16:54:43 <raster> devs git repo > Feb 05 16:54:47 <stefan_schmidt> you mean update when new keys have > been > added? > Feb 05 16:54:53 <raster> get git server to update to use latest > Feb 05 16:54:55 <raster> yes > Feb 05 16:54:58 <stefan_schmidt> there should be a cron job for this > Feb 05 16:55:20 <raster> how often? > Feb 05 16:55:22 <stefan_schmidt> iirc running every 15min or so > Feb 05 16:55:24 <raster> how long do i have to wait? > Feb 05 16:55:52 <stefan_schmidt> but as I don't do admin stuff this is > ju > st from memory > Feb 05 16:58:10 <raster> i cant find the crontab > Feb 05 16:58:12 <raster> grrr > >> you did to break it. Maybe it was the fact that a user called apache >> already exists outside of the user system, the same way I guess creating >> a new dev account for "root" would fail. Not entirely sure though. > > originally this worked when i setup dokuwiki to start with. i added an apache > user to the git devs and everything fell into place. now it does not work.
I said maybe, not conclusively. The issue I fixed was the apache user having access to the git user from outside of gitolite (that was the major one, there were a few smaller ones preventing it from working). I thought maybe it was related. > >>> the dokuwiki commit-back keeps breaking and losing its ssh keys. go back to >>> the old fashioned way of having a key in apache's ~/.ssh and be done with >>> it. it works and is what everyone knows. i have no idea how it's meant to >>> work otherwise >>> >>> just make the danged wiki work and keep working without it falling over >>> then no one having any idea how to fix it. >> >> We elected Beber as our sysadmin. He's been doing a good job. Things >> fail sometimes, and we can talk to him to fix them. I have no idea about >> the setup, he does. All I know (hence my comment) is that you and him >> keep on reverting and mangling each other's work without talking to each >> other. > > the problem is that we have things like our website being screwed up with git > conflicts in it and beber is asleep and not going to fix anything... so i end > up having to do it. sure - he can look at it half a day or a day later or 2... > but we literally had conflicts in our wiki pages because git was not pushing > and eventually got a conflict in. We literally had issues with dokuwiki for weeks before you touched it. Stefan came to me a while back, I thought I fixed it, but I apparently didn't. Had I known, I would have fixed it. > >>> if a setup is so complex no one can figure it out - it's broken. if it >>> breaks then who cares about security when the system is essentially >>> non-functioning. great - it's secure by it never actually working. that's >>> useless. >>> >> >> Again, I'm not in charge of the system, I don't know the setup in its >> entire, but I do know what you did was wrong for our setup, and >> unnecessary. Contacting me would have solved it immediately (which as >> shown, when I saw your hack, I migrated it to the right place and that >> made dokuwiki work again). > > you were not awake or around. you turned up 2hrs later. :) when you did turn > up > you didn't know about the ssh keys: > > Feb 05 18:57:29 <raster> both situations ssh in as the same uid (git) > Feb 05 18:57:34 <raster> but with different pub keys > Feb 05 18:57:39 <TAsn> config > Feb 05 18:57:42 <raster> what/how > Feb 05 18:57:44 <TAsn> different ssh config > Feb 05 18:57:44 <raster> how to fix this? > Feb 05 18:57:48 <TAsn> dunno > Feb 05 18:57:49 <TAsn> ask beber > Feb 05 18:57:53 <raster> errrr > Feb 05 18:58:12 <raster> apache user has no ssh config at all > Feb 05 18:58:15 <raster> not in ~/.ssh > Feb 05 18:59:11 <TAsn> O_o You asked me about dokuwiki, not about setting up keys in the git system. Or more precisely: I don't remember what we were talking about, but whatever that was, I didn't understand you were going to add an apache developer again. > > that's what i mixed up the "don't know" with stefan :) you had no idea how > dokuwiki works with ssh to git.e.org. > >> Anyhow, beber says he fixed the issue, let's see. > > let's hope it stays that way. Yeah. Bottom line though, fixing things is good and all, but we need to have the system correct and consistent so beber can manage it in the little time he has. > >> -- >> Tom. >> >>>> On 05/02/16 07:52, Carsten Haitzler (Rasterman) wrote: >>>>> raster pushed a commit to branch master. >>>>> >>>>> http://git.enlightenment.org/admin/devs.git/commit/?id=a4ff9b51b3e7ca783c578cced5f3ebecd14c58ee >>>>> >>>>> commit a4ff9b51b3e7ca783c578cced5f3ebecd14c58ee >>>>> Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> >>>>> Date: Fri Feb 5 16:50:50 2016 +0900 >>>>> >>>>> Apache user is back - whatever keeps happing on www.e.org to stop >>>>> the wiki from being able to commit and losing its ssh creds is now just >>>>> too painful. do it the good olde way that everyone can deal with - >>>>> ssh pub keys for apache user. >>>>> --- >>>>> developers/apache/id_rsa.pub | 1 + >>>>> developers/apache/info.txt | 7 +++++++ >>>>> 2 files changed, 8 insertions(+) >>>>> >>>>> diff --git a/developers/apache/id_rsa.pub b/developers/apache/id_rsa.pub >>>>> new file mode 100644 >>>>> index 0000000..adaf73c >>>>> --- /dev/null >>>>> +++ b/developers/apache/id_rsa.pub >>>>> @@ -0,0 +1 @@ >>>>> +ssh-rsa >>>>> AAAAB3NzaC1yc2EAAAADAQABAAACAQC5RDOkanPfecjzSiUQI1EdD/n958r/15Ag3f00u8bhdw1PozipuJwgJEQ >>>>> +tDpD2l9q0IqbBzgcDv0Ct1bBQclFH28piwLsPkMhz7plsaM2O1xTKi3rmfQg5EMkCxJV8raGs6zHj4F/ov7N1Qn8EmLy2Nl8Ipg9k63PZNm3tKH >>>>> +rSWgmFKwuZPEOWYa1cQQ6h5boVvvdsniB8OAWM19tCBuvuJjgmz8kEGpdd2Z1C01NWInKC4ic6nu7ZFqHHGc4aEmxjYe7sIo48aIreWk2Y6a1x4 >>>>> +RYv4oEQTZeYUYnTCtZF9SEh9ix4GFsJsKtkk0iRN81Fa >>>>> +zDrsYWyvSwMskHm2hiiDd9n4P1K5c5PUZKjOn0 >>>>> +Ihb4nocepm9zIIZkH79LNlKF/DArMIIBnOYRhVBuiTAqi26WDh+9 >>>>> +iXuCrXxxGcJdsQ7NkXeNwh2VZgUqejlYaD2 [...] diff --git >>>>> a/developers/apache/info.txt b/developers/apache/info.txt new file mode >>>>> 100644 index 0000000..c5a5e3b >>>>> --- /dev/null >>>>> +++ b/developers/apache/info.txt >>>>> @@ -0,0 +1,7 @@ >>>>> +Login: apache >>>>> +IRC Nick: N/A >>>>> +Cloak: N/A >>>>> +Name: Wiki Web Bot >>>>> +WWW: http://www.enlightenment.org >>>>> +E-Mail: n...@anlightenment.org >>>>> +Managing: www-content >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>>> Monitor end-to-end web transactions and take corrective actions now >>>> Troubleshoot faster and improve end-user experience. Signup Now! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>>> _______________________________________________ >>>> enlightenment-devel mailing list >>>> enlightenment-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>> >>> >>> >> > > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
