reqadm-users-l Mailing List for REQADM Helpdesk Request Ticket System
Brought to you by:
rcopeland101,
slw
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(14) |
Dec
|
2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Steve W. <st...@al...> - 2005-01-28 20:35:41
|
On Fri, 28 Jan 2005, Andrey Popovich wrote: > I just downloaded REQADM-1.3.1 from SourceForge and trying to build it > on my FreeBSD 4.11-STABLE machine. After configure script proceed, it > generate Builg.<balh-blah> directory with zero-size Makefile. Is there > some tricks to build it on current BSD releases? That's odd. I just built a copy on a 4.10-RELEASE system. I can't imagine there'd be anything that different in 4.11 to upset REQADM's build. You might want to start by making sure your source tarball isn't corrupt or truncated, or that something didn't interrupt the configure script somehow. > Also is it possible to build client for Windows 2000/XP systems? We did manage to get xreqadm to build on Windows 2000, and it worked reasonably well, but never really finished that off in a production-worthy level before the project ended and transitioned to an Open-Source endeavor. At this point, we're working on our plans for the 2.0 release, which will significantly change how the clients and servers will function, so we haven't gone back to complete the old 1.3 client port to Windows, but plan to have the 2.0 version work with Windows. If you want to take it on yourself, it's not all that complicated to do, if you can just set up the Tcl/Tk libraries on your Windows system and compile it all up. The main problem we had was that in the 1.3 version we use ET (Embedded Tk) to preprocess the Tcl GUI code into C, and this makes source lines too long for Microsoft's C compiler to accept. So you will probably want to use GCC or something. > And final question: maybe you have new version? Or CVS access? We're regrouping a bit after not having a chance to work on REQADM much last year. I was just talking to my co-developer and we're gearing up to plan out the 2.0 release, and we'll make details of that available on the sourceforge site when we have our plans worked out in more detail. -- Steve Willoughby | "It is our choices... that show what we truly <st...@al...> | are, far more than our abilities." | --Albus Dumbledore, in Harry Potter and the | Chamber of Secrets, by J. K. Rowling |
From: Andrey P. <And...@is...> - 2005-01-28 09:06:45
|
Good day, all! I just downloaded REQADM-1.3.1 from SourceForge and trying to build it on my FreeBSD 4.11-STABLE machine. After configure script proceed, it generate Builg.<balh-blah> directory with zero-size Makefile. Is there some tricks to build it on current BSD releases? Also is it possible to build client for Windows 2000/XP systems? And final question: maybe you have new version? Or CVS access? Thanks a lot. --- Andrey Popovich ISS Ltd AP11-UANIC, PAA2-RIPE System Administrator |
From: Steve W. <st...@ic...> - 2004-11-23 17:58:45
|
On Tue, 9 Nov 2004, Steve Willoughby wrote: > Date: Tue, 9 Nov 2004 08:49:36 -0800 (PST) > From: Steve Willoughby <st...@al...> > To: mw...@tt... > Cc: req...@li... > Subject: [REQADM-Users-L] Re: supporting usernames greater than 8 letters > > Matthew White wrote: > > So, it seems that reqadm has a hard limit of 8 characters for the > > Unix username field. Is there a way around this? I tried editing > > and compiling a new schema file, but when I dbinit'd and ran reqadmd, > > it freaked out: > > When you change the schema file you need to do more than that. For the > Perl and Tcl APIs to the database, that would be sufficient. But for > the C/C++ API, the database schema compiler (dbcomp) actually generates > a .h file containing structure/object definitions for each table in the > database. These need to be compiled into REQADM so its data structures > will match what is in the database, or things will get very unhappy. I > am actually out on vacation this week, but I'll see if I can look over the > code for any other potential issues with 8-character logins other than > the database field. For now, I'd recommend not changing that. Besides that, the 8-character limit is too prevalent throughout REQADM, including its client-server protocol. Fortunately, REQADM doesn't use usernames for very much, using the numeric IDs for users as the primary means of keeping them organized, but moving to >8 character logins is not a trivial change. I'll put it on the list of things to do in the near term, while I'm working on the database changes. The client-server protocol will be completely different in 2.0, so I believe by the time we're finished with the 2.0 coding, the 8-character limit will be gone at the same time. -- Steve Willoughby | "The purpose of IT is to seamlessly and trans- Intel DPG Eng. Computing | parently provide the other nine-tenths of the Application Development | iceberg for people who need to work with chunks <st...@ic...> | of floating ice." --Strata R. Chalup |
From: Steve W. <st...@al...> - 2004-11-09 16:53:44
|
Matthew White wrote: > So, it seems that reqadm has a hard limit of 8 characters for the > Unix username field. Is there a way around this? I tried editing > and compiling a new schema file, but when I dbinit'd and ran reqadmd, > it freaked out: When you change the schema file you need to do more than that. For the Perl and Tcl APIs to the database, that would be sufficient. But for the C/C++ API, the database schema compiler (dbcomp) actually generates a .h file containing structure/object definitions for each table in the database. These need to be compiled into REQADM so its data structures will match what is in the database, or things will get very unhappy. I am actually out on vacation this week, but I'll see if I can look over the code for any other potential issues with 8-character logins other than the database field. For now, I'd recommend not changing that. --steve -- Steve Willoughby | "It is our choices... that show what we truly <st...@al...> | are, far more than our abilities." | --Albus Dumbledore, in Harry Potter and the | Chamber of Secrets, by J. K. Rowling |
From: Matthew W. <mw...@tt...> - 2004-11-08 22:22:24
|
So, it seems that reqadm has a hard limit of 8 characters for the Unix username field. Is there a way around this? I tried editing and compiling a new schema file, but when I dbinit'd and ran reqadmd, it freaked out: ./sbin/reqadmd File descriptor limit set to 1024 Reading reqadmd server configuration... database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: search(ss_person_fullname): Null string pointer for word set database error: ffm: set members has no current owner database error: ffm: set owns has no current owner database error: match: db_systemtype has no searchable fields in members. database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: type mismatch database error: match: db_systemtype has no searchable fields in members. database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: fieldID out of range database error: AthenaRecord::setField: type mismatch database error: Duplicate records not allowed in ss_system_type Can't create workgroup /home/reqadm/lib/workgroups.conf: Update of Workgroup data aborted. (status 9: ) Unable to configure server. what else would one need to do? -mtw -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@ic...> - 2004-11-04 17:45:33
|
On Thu, 4 Nov 2004, Matthew White wrote: > okay... so if I manually edit an entry in cdis and up the "last modified > time", run reqadm-nightly, and re-look up the user I should see new > information, yes? As long as what you up the modtime to is newer than the timestamp in REQADM already (and you can check that by viewing the user's profile in xreqadm or on the web tools), then yes. |
From: Matthew W. <mw...@tt...> - 2004-11-04 16:54:25
|
okay... so if I manually edit an entry in cdis and up the "last modified time", run reqadm-nightly, and re-look up the user I should see new information, yes? -mtw On Tue, Nov 02, 2004 at 10:08:38AM -0800, Steve Willoughby (st...@ic...) wrote: > On Tue, 2 Nov 2004, Matthew White wrote: > > thought I had it... now I don't. > > Pretty much. I'll simplify slightly. > > usertable, cdis, password file/NIS, etc. all get loaded into the > REQADM database when you install REQADM and periodically (reqadm-nightly) > thereafter. This is your active customer base. > > REQADM gets a request from someone who isn't in the REQADM database. > > What happens next depends on how we got the person's ticket. If we already > have an RUID, REQADM will just query userinfo to get the info for the > user's account. > > If we only have an email address, it will try LDAP to get a RUID from the > mail address and then ask userinfo. > > If we can't get an RUID, REQADM will invent one in the "temporary RUID" > number range, fill in a few of the profile fields and proceed. > > > SO, if I want to change someone's information, I need to add that person > > to the cdis file and make sure their modification date is later than > > when the user was fist stuffed into the dbase. Then after the nightly > > cron script is run, that user's info will be update. > > Right, except that the date should be later than the last update to the > user's REQADM profile (either from a previous update via cron or the > person editing their profile from within REQADM). > > -- > Steve Willoughby | "The purpose of IT is to seamlessly and trans- > Intel DPG Eng. Computing | parently provide the other nine-tenths of the > Application Development | iceberg for people who need to work with chunks > <st...@ic...> | of floating ice." --Strata R. Chalup > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Reqadm-users-l mailing list > Req...@li... > https://lists.sourceforge.net/lists/listinfo/reqadm-users-l -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@ic...> - 2004-11-02 18:09:41
|
On Tue, 2 Nov 2004, Matthew White wrote: > thought I had it... now I don't. Pretty much. I'll simplify slightly. usertable, cdis, password file/NIS, etc. all get loaded into the REQADM database when you install REQADM and periodically (reqadm-nightly) thereafter. This is your active customer base. REQADM gets a request from someone who isn't in the REQADM database. What happens next depends on how we got the person's ticket. If we already have an RUID, REQADM will just query userinfo to get the info for the user's account. If we only have an email address, it will try LDAP to get a RUID from the mail address and then ask userinfo. If we can't get an RUID, REQADM will invent one in the "temporary RUID" number range, fill in a few of the profile fields and proceed. > SO, if I want to change someone's information, I need to add that person > to the cdis file and make sure their modification date is later than > when the user was fist stuffed into the dbase. Then after the nightly > cron script is run, that user's info will be update. Right, except that the date should be later than the last update to the user's REQADM profile (either from a previous update via cron or the person editing their profile from within REQADM). -- Steve Willoughby | "The purpose of IT is to seamlessly and trans- Intel DPG Eng. Computing | parently provide the other nine-tenths of the Application Development | iceberg for people who need to work with chunks <st...@ic...> | of floating ice." --Strata R. Chalup |
From: Matthew W. <mw...@tt...> - 2004-11-02 17:37:30
|
thought I had it... now I don't. This is the way I think userinfo is working, maybe I'm wrong. REQADM gets a request from someone that doesn't exist in "usertable" or "cdis" or the dbase REQADM asks the LDAP server about this person, LDAP returns a RUID REQADM asks userinfod about this RUID, RUID returns the person's info REQADM takes this info and stuffs it into the dbase SO, if I want to change someone's information, I need to add that person to the cdis file and make sure their modification date is later than when the user was fist stuffed into the dbase. Then after the nightly cron script is run, that user's info will be update. yes? no? -mtw On Mon, Nov 01, 2004 at 02:12:21PM -0800, Matthew White (mw...@tt...) wrote: > okay... this make sense now. > > Taking bits out of the userinfo daemon and generating a cdis info file > out of our LDAP database should be trivial. > > Thanks for your work on this Steve. Reqadm is a really great program > despite the somewhat byzantine back end. I'm looking forward to the > SQL-ized version! > > -mtw > > On Mon, Nov 01, 2004 at 02:06:27PM -0800, Steve Willoughby (st...@ic...) wrote: > > On Mon, 1 Nov 2004, Matthew White wrote: > > > okay, so after looking at the script and re-reading the documentation, > > > having a userinfo daemon doesn't buy you much in terms of dynamic data. > > > Seems to me I still need to populate the cdis file. Is that correct? > > > > The only real advantage to having the userinfo daemon is to dynamically > > pull the info for a user who isn't in the REQADM database at all. In > > the environment where REQADM was born, it was typical for there to be > > a set of many tens of thousands of potential users, but only about 2000 > > active common users, which REQADM really needed to track. So when the odd > > extra user showed up with a request ticket, REQADM would query the userinfo > > service to get their profile on the fly and proceed. It really isn't for > > dynamic updates to existing users. > > > > Which is one reason we're going away from that whole model now. But in > > the mean time, there's really no way to update user info for existing > > people short of running reqadm-update-db (which you shouldn't do while > > the daemon's running... see the reqadm-nightly script for how it puts > > the reqadm server to sleep while running reqadm-update-db). > > > > --steve > > > > -- > Matthew White > District Systems Administrator > Tigard/Tualatin School District > 503.431.4128 > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Reqadm-users-l mailing list > Req...@li... > https://lists.sourceforge.net/lists/listinfo/reqadm-users-l -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@ic...> - 2004-11-01 22:20:37
|
On Mon, 1 Nov 2004, Matthew White wrote: > Thanks for your work on this Steve. Reqadm is a really great program > despite the somewhat byzantine back end. I'm looking forward to the > SQL-ized version! Thanks! I'm trying to make the backend less byzantine :) |
From: Matthew W. <mw...@tt...> - 2004-11-01 22:12:37
|
okay... this make sense now. Taking bits out of the userinfo daemon and generating a cdis info file out of our LDAP database should be trivial. Thanks for your work on this Steve. Reqadm is a really great program despite the somewhat byzantine back end. I'm looking forward to the SQL-ized version! -mtw On Mon, Nov 01, 2004 at 02:06:27PM -0800, Steve Willoughby (st...@ic...) wrote: > On Mon, 1 Nov 2004, Matthew White wrote: > > okay, so after looking at the script and re-reading the documentation, > > having a userinfo daemon doesn't buy you much in terms of dynamic data. > > Seems to me I still need to populate the cdis file. Is that correct? > > The only real advantage to having the userinfo daemon is to dynamically > pull the info for a user who isn't in the REQADM database at all. In > the environment where REQADM was born, it was typical for there to be > a set of many tens of thousands of potential users, but only about 2000 > active common users, which REQADM really needed to track. So when the odd > extra user showed up with a request ticket, REQADM would query the userinfo > service to get their profile on the fly and proceed. It really isn't for > dynamic updates to existing users. > > Which is one reason we're going away from that whole model now. But in > the mean time, there's really no way to update user info for existing > people short of running reqadm-update-db (which you shouldn't do while > the daemon's running... see the reqadm-nightly script for how it puts > the reqadm server to sleep while running reqadm-update-db). > > --steve > -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@ic...> - 2004-11-01 22:07:32
|
On Mon, 1 Nov 2004, Matthew White wrote: > okay, so after looking at the script and re-reading the documentation, > having a userinfo daemon doesn't buy you much in terms of dynamic data. > Seems to me I still need to populate the cdis file. Is that correct? The only real advantage to having the userinfo daemon is to dynamically pull the info for a user who isn't in the REQADM database at all. In the environment where REQADM was born, it was typical for there to be a set of many tens of thousands of potential users, but only about 2000 active common users, which REQADM really needed to track. So when the odd extra user showed up with a request ticket, REQADM would query the userinfo service to get their profile on the fly and proceed. It really isn't for dynamic updates to existing users. Which is one reason we're going away from that whole model now. But in the mean time, there's really no way to update user info for existing people short of running reqadm-update-db (which you shouldn't do while the daemon's running... see the reqadm-nightly script for how it puts the reqadm server to sleep while running reqadm-update-db). --steve |
From: Matthew W. <mw...@tt...> - 2004-11-01 21:53:34
|
okay, so after looking at the script and re-reading the documentation, having a userinfo daemon doesn't buy you much in terms of dynamic data. Seems to me I still need to populate the cdis file. Is that correct? -mtw On Mon, Nov 01, 2004 at 01:28:11PM -0800, Steve Willoughby (st...@ic...) wrote: > On Mon, 1 Nov 2004, Matthew White wrote: > > I'm guessing this is a script that I need to make myself? I didn't > > find anything similar to this in the source distribution. > > It should be in there. Lemme check for sure... > > Yes, these are from the REQADM-1.3.1-src.tar.gz file on sourceforge. > > /scripts/reqadm-nightly > this is the thing to run from cron. It backs up the databases, and > toward the bottom it calls: > "$STATIC_STRING_04/sbin/reqadm-update-db -people" > > /scripts/reqadm-update-db > this is the script to reload/update the database of user preferences > and profiles, etc. If you give it the "-force" option, it'll > unconditionally update everything from userinfo, otherwise it checks > the timestamp in userinfo vs. the timestamp in the REQADM database. > the timestamp is field 39 in the userinfo record, btw. (counting from 0) > > If that doesn't answer your question, let me know and I'll go deeper into > it. > > Steve > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Reqadm-users-l mailing list > Req...@li... > https://lists.sourceforge.net/lists/listinfo/reqadm-users-l -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@ic...> - 2004-11-01 21:50:31
|
On Mon, 1 Nov 2004, Steve Willoughby wrote: > /scripts/reqadm-nightly > this is the thing to run from cron. It backs up the databases, and > toward the bottom it calls: > "$STATIC_STRING_04/sbin/reqadm-update-db -people" .................^^^^^^^^^^^^^^^^^ Just to be complete, $STATIC_STRING_04 is replaced with the name of the directory where these scripts live, when you run the setup program to install REQADM. |
From: Steve W. <st...@ic...> - 2004-11-01 21:29:13
|
On Mon, 1 Nov 2004, Matthew White wrote: > I'm guessing this is a script that I need to make myself? I didn't > find anything similar to this in the source distribution. It should be in there. Lemme check for sure... Yes, these are from the REQADM-1.3.1-src.tar.gz file on sourceforge. /scripts/reqadm-nightly this is the thing to run from cron. It backs up the databases, and toward the bottom it calls: "$STATIC_STRING_04/sbin/reqadm-update-db -people" /scripts/reqadm-update-db this is the script to reload/update the database of user preferences and profiles, etc. If you give it the "-force" option, it'll unconditionally update everything from userinfo, otherwise it checks the timestamp in userinfo vs. the timestamp in the REQADM database. the timestamp is field 39 in the userinfo record, btw. (counting from 0) If that doesn't answer your question, let me know and I'll go deeper into it. Steve |
From: Matthew W. <mw...@tt...> - 2004-11-01 19:31:41
|
On Sat, Oct 30, 2004 at 08:53:48AM -0700, Steve Willoughby (st...@al...) wrote: > On Fri, 29 Oct 2004, Matthew White wrote: > > Ok, so... I've got things smoothly working with reqadm so far... we've > > got users authentication with apache/LDAP and pulling userifo out of a > > home-brew userinfo server. here's the issue: when a users phone number > > is updated in our LDAP database (where the userinfo server is getting > > its information) it's not reflected in a user's "profile" within reqadm. > > Is there a way to change this behavior? > > The way REQADM was designed, it looks for updates from userinfo via > nightly cron job which pulls the userinfo data and merges it with > REQADM's own database. It looks for the modification date (one of > the fields in the userinfo data) and ignores any record which was > modified less recently than REQADM's own profile. So you need to > get that date field updated as well. I'm guessing this is a script that I need to make myself? I didn't find anything similar to this in the source distribution. -mtw -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@al...> - 2004-10-30 15:57:09
|
On Fri, 29 Oct 2004, Matthew White wrote: > Ok, so... I've got things smoothly working with reqadm so far... we've > got users authentication with apache/LDAP and pulling userifo out of a > home-brew userinfo server. here's the issue: when a users phone number > is updated in our LDAP database (where the userinfo server is getting > its information) it's not reflected in a user's "profile" within reqadm. > Is there a way to change this behavior? The way REQADM was designed, it looks for updates from userinfo via nightly cron job which pulls the userinfo data and merges it with REQADM's own database. It looks for the modification date (one of the fields in the userinfo data) and ignores any record which was modified less recently than REQADM's own profile. So you need to get that date field updated as well. I'm working now on the migration of REQADM to SQL, and when that is ready for release, the behavior will be for REQADM to just read the profile table which will be much easier for random site processes to update. This will do away with all the userinfo stuff you see in REQADM today, which is a legacy bridge to the old environment REQADM was originally custom-built for. -- Steve Willoughby | "It is our choices... that show what we truly <st...@al...> | are, far more than our abilities." | --Albus Dumbledore, in Harry Potter and the | Chamber of Secrets, by J. K. Rowling |
From: Matthew W. <mw...@tt...> - 2004-10-29 23:19:27
|
*tap tap* This thing still work? Ok, so... I've got things smoothly working with reqadm so far... we've got users authentication with apache/LDAP and pulling userifo out of a home-brew userinfo server. here's the issue: when a users phone number is updated in our LDAP database (where the userinfo server is getting its information) it's not reflected in a user's "profile" within reqadm. Is there a way to change this behavior? -mtw -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@al...> - 2004-01-03 09:05:00
|
REQADM 1.3.1 is now on reqadm.sourceforge.net. It includes a couple of minor changes discussed recently on this mailing list: + removed blank line in reqadm.conf + fixed bug in the config file scanning code which made the blank line a serious problem. + added reqadm-config.pl which was inadvertently omitted from 1.3. -- Steve Willoughby | "It is our choices... that show what we truly <st...@al...> | are, far more than our abilities." | --Albus Dumbledore, in Harry Potter and the | Chamber of Secrets, by J. K. Rowling |
From: Steve W. <st...@al...> - 2003-12-21 09:48:05
|
Tom Ivar Helbekkmo wrote: > It's an error in the supplied reqadm.conf.sample, where there's a > blank line accidentally inserted after the line setting a value for > the AHQU parameter. This blank line causes reqadmd to silently ignore > the rest of the config file, thus missing a lot of settings. *blink* Good catch! 1.3.1 will contain a fixed reqadm.conf.sample file, and hopefully a fix to the config file scanning code so that it won't break on blank lines :) Thanks! steve -- Steve Willoughby | "It is our choices... that show what we truly <st...@al...> | are, far more than our abilities." | --Albus Dumbledore, in Harry Potter and the | Chamber of Secrets, by J. K. Rowling |
From: Tom I. H. <ti...@eu...> - 2003-12-21 07:25:26
|
Tom Ivar Helbekkmo <ti...@eu...> writes: > I'll do some more digging. Ha! I found it! :-) It's an error in the supplied reqadm.conf.sample, where there's a blank line accidentally inserted after the line setting a value for the AHQU parameter. This blank line causes reqadmd to silently ignore the rest of the config file, thus missing a lot of settings. After removing the blank line from my reqadm.conf, things work. :-) -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
From: Tom I. H. <ti...@eu...> - 2003-12-20 19:06:50
|
Steve Willoughby <st...@al...> writes: > Okay, now that's strange then. Let me see if I can figure out how > this could have happened. Looks like corruption of the malloc arena: #0 0x08061bdb in ConfigItemTable::findItem(unsigned long) (this=0x824fc20, id=1095258964) at config.cc:87 87 if (n->ID == id) return n; (gdb) print n $1 = (ConfigItemNode *) 0x1 (gdb) print id $2 = 1095258964 (gdb) print ConfigHashSize $42 = 32 (gdb) print id % ConfigHashSize $44 = 20 (gdb) print table[20] $45 = (ConfigItemNode *) 0x852d330 (gdb) print *table[20] $46 = {ID = 139026144, value = {number = 139584136, string = 0x851e288 "\002"}, next = 0x1} Since 'next' can, from inspection of the code, not be set to 1, something seems to have stomped on parts of the memory involved. I'll do some more digging. -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
From: Tom I. H. <ti...@eu...> - 2003-12-19 06:01:17
|
Steve Willoughby <st...@al...> writes: > However, I'm starting to think that it would have been easier to > just hard-code a path to a configuration file somewhere in the > build process and allow run-time overrides to that. With the move to a server side relational database, all configuration data should be in the database, except, on the server, a minimal configuration file telling little more than how to find the database, and, on a client, one telling little more than how to find the server. -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
From: Matthew W. <mw...@tt...> - 2003-12-18 22:01:53
|
Awesome, thanks! -mtw On Thu, Dec 18, 2003 at 01:47:07PM -0800, Steve Willoughby (st...@al...) wrote: > In message <200...@pd...>, Rusty Copeland > writes: > >In the source code, after it has been configured, there is a file > >named config.conf. This is very similar to the install config file. > >If you set this file up with the values of the install config these > >values will be built into the binary you are trying to create. > > This only works if -DREQADM__DEVEL is also defined at compile time. > (This switches in the values from config.conf instead of the > placeholders setup is looking for.) > > Running configure with the -d option will set all that up for you. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Reqadm-users-l mailing list > Req...@li... > https://lists.sourceforge.net/lists/listinfo/reqadm-users-l -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
From: Steve W. <st...@al...> - 2003-12-18 21:57:20
|
In message <200...@pd...>, Rusty Copeland writes: >In the source code, after it has been configured, there is a file >named config.conf. This is very similar to the install config file. >If you set this file up with the values of the install config these >values will be built into the binary you are trying to create. This only works if -DREQADM__DEVEL is also defined at compile time. (This switches in the values from config.conf instead of the placeholders setup is looking for.) Running configure with the -d option will set all that up for you. |