Context below.
<mchua> itbegins: thanks! the other thing I wanted to ask you about is fasauth, since the module (as currently packaged and deployed on pt6) doesn't seem to be working atm
<itbegins> the package is out of date
<itbegins> source from git should work fine
<itbegins> mchua: So really, we need to get the package updated asap
<itbegins> mchua: Also, remember it authenticates against test fas, not real fas
<mchua> itbegins: gotcha. do you have the bandwidth to do that or should i go drum up some packaging help?
<itbegins> mchua: I'd grab a drum, I don't have the know how to do that
<mchua> itbegins: Ok; I'll make sure that happens, then. basically, whatever is in git is the final thing that needs to be packaged?
<itbegins> mchua: Theoretically, yes, though there's always a chance i'll need to revise it once more
<mchua> itbegins: since we'll need to change it again for the "authenticates on real fas" stuff once we're off publictest - how do you want to handle that?
<itbegins> mchua: THat will be handled via puppet I believe, I separated out the configuration file
<mchua> itbegins: ah, okay, so once it's packaged here, we don't need to repackage again to switch from fake to real fas auth?
<itbegins> mchua: nope, no need
<mchua> excellent
<itbegins> mchua: That's one of the changes in the new code
<mchua> itbegins: great. Ok, I'll add these two things to the ticket queue now so we can keep track of them, and assign the second one to myself and get that packaging taken care of
The source is in git, in project 'fedora-zikula' (see source at https://fedorahosted.org/fedora-zikula/browser/AuthFAS) - the stuff here just needs to be packaged up.
There. Now that I've found the repo, opening the ticket so somebody faster at packaging can take it...
There is a fasauth package already in the infra repo. There has even been a 0.2 release of the fasauth package updating some of the code that Simon changed.
I just checked my local copy of fedora-zikula repo and pulled from fh.o, and the copy on my local machine reports that it's already up to date, meaning there has been nothing pushed to fh.o since I built the 0.2 packages.
Source rpm is here and has been since 28 August: http://ke4qqq.fedorapeople.org/zikula-module-fedora-fasauth-0.2-1.fc11.src.rpm
I'll copy this to the ticket as well.
Mel: Assuming this fixes the problem, please close the ticket.
"What's up with fasauth?" convo in #fedora-admin
<mchua> mmcgrath: this is probably my inexperience here, but it looks like (1) simon fixed the code in git (2) the most recent code in git is packaged (2) that package is what was deployed on pt6 (3) fasauth does not work on pt6
<mchua> mmcgrath: I'm trying to figure out where in this chain my assumptions are wrong
<mmcgrath> mchua: correct. that's my understanding as well.
<mmcgrath> I suspect the new package is just misconfigured but I'm not quite sure how to configure it.
<mmcgrath> I know where to configure it, but when I set the bits I thought needed to be set (in staging) it still didn't seem to work
<mchua> mmcgrath: How would you attack this problem? I can try to do that later this evening, after my chain of meetings finishes up.
<mmcgrath> I'd start with seeing if simon can look at it on pt6
<mmcgrath> he'd probably be able to tell, almost immediately, what was wrong
Update on fasauth issue
22:25 < ke4qqq> itbegins: ping 22:25 < itbegins> ke4qqq: Hi 22:25 < ke4qqq> hi 22:26 < ke4qqq> so do you have a minute to talk about fasauth 22:26 < itbegins> ke4qqq: Yep... 22:26 < ke4qqq> so....it doesn't work 22:26 < itbegins> I realise everyone has been running aroud looking for me... 22:26 < ke4qqq> and that's with the latest code that is in git 22:26 < itbegins> ke4qqq: Yes, so the immediate thing that springs to mind is this: 22:26 < itbegins> ke4qqq: It requires that the file in modules/AuthFas/config gets moved to the config directory 22:27 * ke4qqq goes to look 22:27 < G_work> mmcgrath: smolt related could prob extend your latest commit to also do that for OEM/Unknown 22:27 < G_work> mmcgrath: ASUS is another one it seems 22:28 < ke4qqq> so that's just a packaging issue then - does it keep personal_config.php name?? seems like a namespace collision would happen there 22:29 < itbegins> ke4qqq: So, this is the file that defines where to look for FAs 22:29 < ke4qqq> right 22:30 < itbegins> ke4qqq: In theory, it can overwrite a file of the same name 22:30 < itbegins> ke4qqq: especially if we run multiple zikula instances from one file system 22:30 < ke4qqq> but if it's tossed into zikulas config dir how do you guarantee that no other module will use that name 22:30 < G_work> mmcgrath: hmmm and noone has registered a 96 core machine to Smolt? thats not on :) 22:31 < itbegins> ke4qqq: Really, personal_config.php should be puppetized 22:31 < itbegins> ke4qqq: It should contain the DB details, and the FAS details, for any production Zikula instances we have 22:32 < ke4qqq> so I understand that - but my question is around what happens when some other module is introduced that wants to use personal_config.php as a config file name 22:32 < ke4qqq> or perhaps I am just being dense and not getting it 22:32 < ke4qqq> anyone care if I condrestart httpd on pt6? 22:33 < itbegins> ke4qqq: So, personal_config.php is a developer-aimed file 22:34 < itbegins> ke4qqq: No modules should write to that file, I'm just using it because I have knowledge of Zikula internals and I know it works in our situation 22:34 < itbegins> ke4qqq: And, following discussions with abadger1999 it's better to have the FAS URL in a file than, for example, in the db 22:35 < ke4qqq> ahhhhh what should it be going forward? for instance $modulename_config.php ?? 22:37 < itbegins> ke4qqq: So, personal_config.php is included by the Zikula config.php to allow developers to override configuration settings and avoid accidentally commiting the overrides to source control. 22:37 < itbegins> ke4qqq: In our case, we'll use it to switch database details dependent on the domain (so different details for docs. than fedora insight) 22:38 < ke4qqq> ahhhh cool 22:38 < itbegins> ke4qqq: And we'll also use this file to define fedora-specific "configuration details" 22:38 < ke4qqq> can you poof me as a cmsadmin in fas test 22:38 < itbegins> ke4qqq: In general, we encourage developers to make their module details configurable by the admin interface (And thus stored in the database) 22:39 < itbegins> ke4qqq: But, for example, if an SQL injection is discovered we don't want a hacker changing the FAS URL so they can harvest passwords 22:39 < itbegins> ke4qqq: So we're borrowing the config file to hard code the FAS URL 22:39 < itbegins> ke4qqq: And in reply to the admin, sure, if I can find my pw 22:40 < ke4qqq> ok - I understand now 22:41 < itbegins> ke4qqq: approved :) 22:42 < ke4qqq> cool !!! and it appears to work 22:42 < ke4qqq> awesome 22:43 < ke4qqq> so since the 'thought' is that fas auth is going to go public - should we keep that file in the module configdir and just add a readme that notes where it goes (I don't want to overwrite someones devel config by putting it there in the package) 22:44 < itbegins> ke4qqq: Yeah, I think so - the documentation at the moment consists of the CVS commit :) 22:44 < itbegins> ke4qqq: Correction, the git commit :) 22:45 < ke4qqq> ok - I'll add a readme file in the next day or so. 22:45 < jds2001> ke4qqq: that's what %config(noreplace) is for :) 22:47 < ke4qqq> jds2001: ohhhh yeah - good idea. slaps forehead 22:49 < ke4qqq> itbegins: thanks for the help - I think it's working properly now. - I'll post the log of this shortly
IT WORKS! (manually installed srpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=1669749, thanks mdomsch, itbegins, and ke4qqq! Now we just need to get it into epel-testing.
ke4qqq, can you run 'make tag build update'? That should take care of this ticket.
keqqq reports this is in the appropriate repos. closing.
Milestone F12b: Alpha to Beta deleted
Login to comment on this ticket.