<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
<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
Source rpm is here and has been since 28 August:
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
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
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.7.1 — Documentation