reqadm-users-l Mailing List for REQADM Helpdesk Request Ticket System (Page 2)
Brought to you by:
rcopeland101,
slw
Menu
▾
▴
reqadm-users-l — Announcements and general discussion by REQADM users.
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: Rusty C. <rco...@ic...> - 2003-12-18 21:45:41
|
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 should work with the sourceforge distribution but have not had time to validate this as yet. It use to be the case that the source code was mainly for the server and the clients had their own directory. Each directory will have it's own config.conf. Below is a sample config.conf file: string 1 32 reqadm.myserver.com#REQADM server hostname string 2 32 /usr/bin/perl#Pathname to execute Perl 5 interpreter at your s ite string 3 80 /var/spool/reqadm/mail#Directory where mail is spooled before submission to REQADM string 4 80 /opt/reqadm#REQADM home directory string 5 80 /usr/bin/gtar#Pathname to GNU Tar on your system string 6 80 /images/reqadm#Pathname to REQADM web images (from WWW document root ) string 7 80 /reqadm#Pathname to REQADM web directory (from WWW document root) string 8 80 /cgi-bin/reqadm#Pathname to REQADM's CGI-BIN directory (from WWW document root) string 9 80 /usr/local/Reqadm#Pathname to directory where REQADM clients will be installed number 1 6666 REQADM server TCP port number number 2 1111111111 Your assigned site code "A" number 3 2222222222 Your assigned site code "B" number 4 99 REQADM Administrative account user ID number Rusty > Matthew White <mw...@tt...> writes: > > > I'm attempting to hack in LDAP authentication support. How can I just > > rebuild reqadmd and run it without it complaining about it not being > > installed properly? > > AOL! ...that is, I'd like to know how to do this for xreqadm, so that > I can debug my problems with that program without the complete install > from scratch cycle for every little change. > > -tih > -- > Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway > www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 > > > ------------------------------------------------------- > 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 > |
|
From: Steve W. <st...@al...> - 2003-12-18 21:44:38
|
In message <200...@tt...>, Matthew White writes: >I'm attempting to hack in LDAP authentication support. How can I just >rebuild reqadmd and run it without it complaining about it not being >installed properly? I'd like to see the whole setup program depricated as we go on with development. It really just serves two purposes: (1) an interactive guide through the too-complicated install process, and (2) (most important for your question) it takes a handful of site-specific numbers and strings and writes them into all the files which were installed. This was considered a good idea at the time, as it meant that any random customer's copy of xreqadm would always point back to our server and know how to talk to it, without needing to answer calls from people who couldn't configure their clients, etc. 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. (Remember that originally we were only able to give out binary copies, not sources.) Anyway, the point is that if you had another way to get your site values into the program when it's compiled, you'd never need to run setup at all. Here's how you do that: (This is a sort of an unadvertised feature, so I haven't tested it with the latest release, but I know of no reason it shoulnd't work with the changes most recently made.) In the src directory, you'll notice various config.* files. These define what site parameters will be installed by "setup". The default one used is config.conf, which looks like this: string 1 32 reqadm.mydomain.com#REQADM server hostname \____/ | \/ \_________________/ \____________________/ | | | | | type ID maxsize value setup prompt number 1 6688 REQADM server TCP port number \____/ | | \___________________________/ | | | | type ID value setup prompt You'll also note the src directory has some other config files, like config.internal - internally built copies config.exp - experimental build config.<whatever> - whatever When you run ./configure to create a build directory, you can give it the following options: -d use config.internal, don't require setup -e use config.exp, don't require setup -dc foo use config.foo, don't require setup Using these options causes configure to arrange the Makefile so that the binaries are built with the contents of the config.* file (which will always be copied as "config.conf" in the build directory) in a ready-to-use form, rather than just a placeholder for "setup" to fill in. In other words, you can execute immediately after building the new binaries. so: 1. Edit src/config.internal to have the values you typed in to "setup". Read the comments in that file for important considerations. 2. ./configure -d 3. cd Build.<blah> 4. hack 5. make 6. run 7. goto 4 |
|
From: Tom I. H. <ti...@eu...> - 2003-12-18 20:20:08
|
Matthew White <mw...@tt...> writes: > I'm attempting to hack in LDAP authentication support. How can I just > rebuild reqadmd and run it without it complaining about it not being > installed properly? AOL! ...that is, I'd like to know how to do this for xreqadm, so that I can debug my problems with that program without the complete install from scratch cycle for every little change. -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 19:39:08
|
Hello- I'm attempting to hack in LDAP authentication support. How can I just rebuild reqadmd and run it without it complaining about it not being installed properly? -mtw -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
|
From: Steve W. <st...@al...> - 2003-12-15 17:02:17
|
In message <86w...@at...>, Tom Ivar Helbekkmo writes: >Lists are often configured so that subscribers can post to them. Is >that a possible option at Sourceforge, I wonder? It's a bit of paranoia I've learned to engage when setting up a new list. It seems like all too often when you start a new list with an old list of people, the first thing to hit the list is a flurry of "hey, take me off this list" spams. Fortunately, that didn't happen here :) I've gone ahead and opened up posting for any subscribed member. If there ever develops a spam problem on the list, I'll deal with it at that point. >(Also, this business of putting the name of the list in brokets at the >start of the subject string is just plain silly: it adds absolutely >nothing useful¹, and takes up string space so that long subject strings >disappear out of the right hand side of many mail reader windows...) I don't have a strong feeling on that one way or another. I do want to provide subscribers with a way to filter the mail, and there are other headers attached which can be used. I'll put this out to the membership here, in case anyone does need the subject tag retained. If you want to keep the [REQADM-Users-L] on the subjects, please send me mail (directly, not to the whole list). Otherwise, do nothing. If I don't hear a significant objection, I'll drop it in a couple of days. |
|
From: Steve W. <st...@al...> - 2003-12-15 15:09:37
|
> > FLG#=%000110011-000000000000011111---
>
> ..and I've left it like that in reqadm.conf. All I've done in
> reqadm.conf is change a couple of paths, urls and email addresses,
> really:
Okay, now that's strange then. Let me see if I can figure out how
this could have happened.
--
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-15 09:47:59
|
req...@li... writes: > Your mail to 'Reqadm-users-l' with the subject > > Re: [REQADM-Users-L] REQADM on NetBSD > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post to moderated list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. Lists are often configured so that subscribers can post to them. Is that a possible option at Sourceforge, I wonder? (Also, this business of putting the name of the list in brokets at the start of the subject string is just plain silly: it adds absolutely nothing useful=B9, and takes up string space so that long subject strings disappear out of the right hand side of many mail reader windows...) -tih =B9...and if you can sort messages into folders based on subjects, you can sort on other header fields as well, getting the same effect. --=20 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-15 09:40:28
|
Steve Willoughby <st...@al...> writes: > That's FLG#, the REQADM main option flag variable. (46=F 4C=L 47=G 23=#) > If your file is missing that, there's a lot of things that aren't going to\ > work. The default that ships with REQADM is: > > FLG#=%000110011-000000000000011111--- ...and I've left it like that in reqadm.conf. All I've done in reqadm.conf is change a couple of paths, urls and email addresses, really: *** reqadm.conf.sample Sat Dec 6 18:11:27 2003 --- reqadm.conf Sat Dec 6 20:07:37 2003 *************** *** 124,140 **** # # What is the name of your computing support center? # ! SUPN=XYZ Engineering Computing # # What is the phone number of your support center where customers # should call your helpdesk? # ! SUPP=555-9999 # # To what E-mail address should customers write when escalating a # problem they don't feel is being adequately addressed? # ! ESCA=sup...@xy... # # ############################################################################## --- 124,140 ---- # # What is the name of your computing support center? # ! SUPN=Hamartun # # What is the phone number of your support center where customers # should call your helpdesk? # ! SUPP=93013940 # # To what E-mail address should customers write when escalating a # problem they don't feel is being adequately addressed? # ! ESCA=ti...@ha... # # ############################################################################## *************** *** 351,357 **** # # URLP: common prefix for all following URLs # ! URLP=http://www.mydomain.com # # UCRE, UFIN, UVIE, UPRE: URLs to REQADM CGI programs. URLP (above) is # prepended to these when necessary, but not whenever we can avoid --- 351,357 ---- # # URLP: common prefix for all following URLs # ! URLP=http://www.hamartun.priv.no # # UCRE, UFIN, UVIE, UPRE: URLs to REQADM CGI programs. URLP (above) is # prepended to these when necessary, but not whenever we can avoid *************** *** 370,376 **** # # What is the URL of the REQADM web homepage? # ! UHOM=http://www.mydomain.com/reqadm/ # # If you want to include your own text or hyperlinks in the # REQADM home page, include any HTML code you wish in the HIL@= --- 370,376 ---- # # What is the URL of the REQADM web homepage? # ! UHOM=http://www.hamartun.priv.no/reqadm/ # # If you want to include your own text or hyperlinks in the # REQADM home page, include any HTML code you wish in the HIL@= *************** *** 398,434 **** # # default domain to be added to "user@host" addresses # ! DDOM=xyz.com # # default hostname to be added to "user" addresses (no @host.domain). # ! DEFH=mydept.xyz.com # # mail hub REQADM should contact to send SMTP mail. # ! MHUB=mail.mydept.xyz.com # # Return address and full name for REQADM's mail. # There needs to be an alias for this which runs the # reqadm-mail-receiver program as explained in the installation # instructions. # ! RADR=re...@my... ! RNAM=XYZ Request Administration # # The address who should be notified of request resolutions and # commitments. # ! FOWN=ma...@my... # # Address to which users should send mail to submit a normal request # ! REQA=he...@my... # # Address to which users should send mail to submit test requests # (the on-line tutorial uses this to demonstrate mailed requests). # ! TSTA=tes...@my... # # What addresses are not allowed to send mail into REQADM? # This is to try to keep down automated mail, especially bounces, --- 398,434 ---- # # default domain to be added to "user@host" addresses # ! DDOM=hamartun.priv.no # # default hostname to be added to "user" addresses (no @host.domain). # ! DEFH=hamartun.priv.no # # mail hub REQADM should contact to send SMTP mail. # ! MHUB=smtp.hamartun.priv.no # # Return address and full name for REQADM's mail. # There needs to be an alias for this which runs the # reqadm-mail-receiver program as explained in the installation # instructions. # ! RADR=re...@ha... ! RNAM=Hamartun Request Administration # # The address who should be notified of request resolutions and # commitments. # ! FOWN=ti...@ha... # # Address to which users should send mail to submit a normal request # ! REQA=re...@ha... # # Address to which users should send mail to submit test requests # (the on-line tutorial uses this to demonstrate mailed requests). # ! TSTA=aut...@ha... # # What addresses are not allowed to send mail into REQADM? # This is to try to keep down automated mail, especially bounces, *************** *** 528,539 **** # Command to print to a PostScript printer # This will be run by the *client* so it needs to work on all your platforms. # ! LPRC=lpr # # Mail command. Must recognize "-s subject address..." syntax #XXX This only needs to be available on the server machine. # ! MAIL=/usr/ucb/mail # # Pager software. Invoked using this syntax: # <commandpath> [-q] <username> {<message> | -} --- 528,539 ---- # Command to print to a PostScript printer # This will be run by the *client* so it needs to work on all your platforms. # ! LPRC=/usr/local/bin/lpr # # Mail command. Must recognize "-s subject address..." syntax #XXX This only needs to be available on the server machine. # ! MAIL=/usr/bin/Mail # # Pager software. Invoked using this syntax: # <commandpath> [-q] <username> {<message> | -} *************** *** 589,595 **** # REQADM-USERINFO(5). For historical reasons, this field is # called "CDIS". # ! CDIS=/usr/local/adm/employees.tab # # Path to "usertable" file for your local users, including # computing staff members. This file has the format: --- 589,595 ---- # REQADM-USERINFO(5). For historical reasons, this field is # called "CDIS". # ! CDIS=/usr/local/reqadm/local/employees.tab # # Path to "usertable" file for your local users, including # computing staff members. This file has the format: *************** *** 597,609 **** # faceless accounts or group accounts have a non-numeric value # for id like "NOTAPRSN". These are ignored by REQADM. # ! USRT=/usr/local/adm/usertable # # Shell-style glob pattern for all the off-site usertable files # you want to include in your database of regular users. # Just leave as "USRG=" if you don't have any of these files. # ! USRG=/usr/local/adm/remote/usertable* # # Administrative and other "fake" users which should be defined # in the REQADM database, but will have IDs out of the RUID range --- 597,609 ---- # faceless accounts or group accounts have a non-numeric value # for id like "NOTAPRSN". These are ignored by REQADM. # ! USRT=/usr/local/reqadm/local/usertable # # Shell-style glob pattern for all the off-site usertable files # you want to include in your database of regular users. # Just leave as "USRG=" if you don't have any of these files. # ! USRG= # # Administrative and other "fake" users which should be defined # in the REQADM database, but will have IDs out of the RUID range *************** *** 618,624 **** # just put the path here, like: PASS=/etc/passwd # If you run a command, specify with | like: PASS=|ypcat passwd # ! PASS=|ypcat passwd # ############################################################################## # --- 618,624 ---- # just put the path here, like: PASS=/etc/passwd # If you run a command, specify with | like: PASS=|ypcat passwd # ! PASS=/etc/passwd # ############################################################################## # *************** *** 632,638 **** # # LDAP server hostname # ! LDAP=dataserver.xyz.com # # LDAP service port # --- 632,638 ---- # # LDAP server hostname # ! LDAP= # # LDAP service port # *************** *** 668,675 **** # REQADM sources include the file "extras/userinfod" which is a sample # userinfo server written in Perl. # ! CDL@=dataserver.xyz.com ! CDL@=dataserver2.xyz.com # # USERINFO service TCP port # --- 668,674 ---- # REQADM sources include the file "extras/userinfod" which is a sample # userinfo server written in Perl. # ! CDL@= # # USERINFO service TCP port # *************** *** 697,703 **** # area code are automatically stripped to a 7-digit phone number in # REQADM. # ! AREA=503 # ############################################################################## # --- 696,702 ---- # area code are automatically stripped to a 7-digit phone number in # REQADM. # ! AREA= # ############################################################################## # -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
|
From: Steve W. <st...@al...> - 2003-12-15 08:45:41
|
Oh, and I forgot to mention, if you just install the reqadm-config.pl
right into your sbin directory, you'll neet to set $STATIC_STRING_04 to
your REQADM server home directory ("/opt/reqadm" or whatever). The
setup program would normally have done that for you.
--
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-15 08:21:45
|
> One needed change is the decoupling of the dependencies on scwoop and > stooop. I had the latter installed, as part of tcllib, but the REQADM > build insisted that I reinstall it in the same directory where I > installed scwoop. Yeah, they're better decoupled than they used to be, but we can make it so the configure script will look for them in separate directories as well. > OK -- I guess I'll give it another go, and this time change nothing. > You can't have gotten everything to work, though, as there's no sign > of a "reqadm-config.pl" in the distribution, and that's needed for the > cron jobs. ;-) Great. That did get left out of the distribution. Okay, sounds like we'll be seeing a 1.3.1 soon. Until then, it's attached to this mail (hopefully the attachment will survive the mail list system; I haven't tried that before). > Then, I run xreqadm, and try to create a new ticket. It suggest me as > the submitter, and when I press "Ok", I get a dialog saying "464C4723: That's FLG#, the REQADM main option flag variable. (46=F 4C=L 47=G 23=#) If your file is missing that, there's a lot of things that aren't going to\ work. The default that ships with REQADM is: FLG#=%000110011-000000000000011111--- > OK, I'm attaching three files: the first is what I did in the src > directory to get it to configure for NetBSD (really just a copy of the > FreeBSD setup). The next is the diff for the Makefiles in the build Thanks for the diffs. We'll start a "NetBSD" configure option with those. > directories, as needed to get things built. (What's libttf? I didn't > have one, so I just ripped it out of the link statement.) Finally, > my Makelog from the build, showing the warnings I mentioned. A true-type font library. It's not used directly by REQADM, but one of the other graphics libs used to complain if it wasn't included as well. If you get a clean compile without it, you don't need it. --steve |
|
From: Tom I. H. <ti...@eu...> - 2003-12-15 07:17:45
|
-tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
|
From: Steve W. <st...@al...> - 2003-12-15 02:30:26
|
In message <86f...@at...>, Tom Ivar Helbekkmo writes: >It's taking me some time, actually. Christmas preparations have >started, and spare time is not copious. :-) I did manage to get the Yeah, for me as well, so we'll see how kind the holidays are to making more progress on the new REQADM database module. :) >whole thing compiled and linked under NetBSD-current, with GCC 3.3, >but not without a few tweaks¹. Some of the supporting software is >sufficiently non-obvious to install for those of us who haven't yet >studied the intricacies of TCL module management, that I believe the >REQADM installation instructions should cover the process in detail. We're trying, with each release, to both document the process better, and to make the process less daunting to begin with. We think that improved a bit in 1.3, but there's obviously more room for improvement. >The change to a relational data base for all configuration info and >tickets will be welcome. The number and opacity of the configuration >files to edit or create from scratch in order to get to where one can >see what REQADM looks like is downright scary. I tried to do it with >as few changes to the distributed files as possible, and really >thought I did everything, and did it right, but I guess I haven't, >because xreqadm gives me lots of "Unable to look up token" dialogs, >and dumps core during attempts to create or edit tickets. I'll just >have to go through the whole process again, I guess. Hm. The process is too hard, yes, but I was able to install the whole thing on FreeBSD without changing any of the config files (I think--or at least very little change) and got it to run. I wonder what else might be giving you that trouble, if you're not actually deleting any reqadm.conf records... >¹ For instance, c++ has to be called with "-Wno-deprecated -fpermissive" > to stop it complaining about old-fashioned code, and to make it let > the following gem be a warning, and not an error (in many places): Sigh. It seems like with every release of GCC there's a new idea about what's depricated, what's a warning, etc. I didn't get much, if any, complaints from the stock GCC on FreeBSD 4.8, so it's interesting what difference there is between those versions of GCC. > For those who, like me, find that message less than lucid, it means > that if you're going to access characters in String objects using > "something[n]", then 'n' must be a long, not an int. :-) I'll look at that. thanks for the feedback, steve |
|
From: Tom I. H. <ti...@eu...> - 2003-12-14 15:23:42
|
I wrote:
> I'd like to a) get 1.3 up and running, and then b) start rewriting
> the database access code as soon as possible...
It's taking me some time, actually. Christmas preparations have
started, and spare time is not copious. :-) I did manage to get the
whole thing compiled and linked under NetBSD-current, with GCC 3.3,
but not without a few tweaks=B9. Some of the supporting software is
sufficiently non-obvious to install for those of us who haven't yet
studied the intricacies of TCL module management, that I believe the
REQADM installation instructions should cover the process in detail.
The change to a relational data base for all configuration info and
tickets will be welcome. The number and opacity of the configuration
files to edit or create from scratch in order to get to where one can
see what REQADM looks like is downright scary. I tried to do it with
as few changes to the distributed files as possible, and really
thought I did everything, and did it right, but I guess I haven't,
because xreqadm gives me lots of "Unable to look up token" dialogs,
and dumps core during attempts to create or edit tickets. I'll just
have to go through the whole process again, I guess.
-tih
=B9 For instance, c++ has to be called with "-Wno-deprecated -fpermissive"
to stop it complaining about old-fashioned code, and to make it let
the following gem be a warning, and not an error (in many places):
encoderdef.cc:114: warning: ISO C++ says that `char& String::operator[](l=
ong=20
int)' and `operator[]' are ambiguous even though the worst conversion =
for=20
the former is better than the worst conversion for the latter
For those who, like me, find that message less than lucid, it means
that if you're going to access characters in String objects using
"something[n]", then 'n' must be a long, not an int. :-)
--=20
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway
www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901
|
|
From: Steve W. <st...@al...> - 2003-12-05 18:05:45
|
In message <200...@tt...>, Matthew White writes: >okay, the issue was with reqadm.conf. I thought I'd save time by using >my old .conf file. Guess that didn't work. :) > >I can still run gdb on the core file(s) I have if you'd like. No, if you found the missing conf line that explains the problem. |
|
From: Matthew W. <mw...@tt...> - 2003-12-05 17:50:05
|
okay, the issue was with reqadm.conf. I thought I'd save time by using my old .conf file. Guess that didn't work. :) I can still run gdb on the core file(s) I have if you'd like. -mtw On Fri, Dec 05, 2003 at 09:03:30AM -0800, Steve Willoughby (st...@al...) wrote: > In message <200...@tt...>, Matthew White writes: > >Trying to get 1.3 working on a debian 3.0 box. I managed to get > >everything complied and installed. When I try to create tickets via email > >(reqadm-create -m) or via the X client I get segfaults. > > Interesting. I don't have debian here to test with. 1.3 does work > on FreeBSD 4.8, though, which is a very similar set of GNU compilers > and libs, etc. Did you get a coredump file? If you feel energetic, > you can try to bring that up in gdb or ddd and see where the offending > line seems to be. > > >The tickets do make it into the system but somewhere along the line it > >dumps core. Along with this, I see the error mesasge "REQADM Server > >Error: Unable to look up token". I haven't been able to determine > >which token REQADM is unable to look up. > > Ah, actually this may be the source of the problem. If you are missing > a field in reqadm.conf, that will make REQADM segfault, unfortunately. > I'd check your reqadm.conf file vs. the reqadm.conf.sample supplied > with REQADM and make sure there are no fields missing (most can be > defined to no value as in: > > XYZQ= > > rather than deleting the line altogether. The coredump file should help > here, if you can see the value of u on line 1258 right before the > segfault. That'll be a 32-bit number equivalent to the four-byte > token name. If you start reqadm-create with the -zdebug option, you > should see a "$<number>" (e.g., "$4A593630") command prior to the > segfault. That would be the number you're looking for as well > (in hex). > > > ------------------------------------------------------- > 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-05 17:11:51
|
In message <200...@tt...>, Matthew White writes: >Trying to get 1.3 working on a debian 3.0 box. I managed to get >everything complied and installed. When I try to create tickets via email >(reqadm-create -m) or via the X client I get segfaults. Interesting. I don't have debian here to test with. 1.3 does work on FreeBSD 4.8, though, which is a very similar set of GNU compilers and libs, etc. Did you get a coredump file? If you feel energetic, you can try to bring that up in gdb or ddd and see where the offending line seems to be. >The tickets do make it into the system but somewhere along the line it >dumps core. Along with this, I see the error mesasge "REQADM Server >Error: Unable to look up token". I haven't been able to determine >which token REQADM is unable to look up. Ah, actually this may be the source of the problem. If you are missing a field in reqadm.conf, that will make REQADM segfault, unfortunately. I'd check your reqadm.conf file vs. the reqadm.conf.sample supplied with REQADM and make sure there are no fields missing (most can be defined to no value as in: XYZQ= rather than deleting the line altogether. The coredump file should help here, if you can see the value of u on line 1258 right before the segfault. That'll be a 32-bit number equivalent to the four-byte token name. If you start reqadm-create with the -zdebug option, you should see a "$<number>" (e.g., "$4A593630") command prior to the segfault. That would be the number you're looking for as well (in hex). |
|
From: Matthew W. <mw...@tt...> - 2003-12-05 00:02:07
|
Hello- Trying to get 1.3 working on a debian 3.0 box. I managed to get everything complied and installed. When I try to create tickets via email (reqadm-create -m) or via the X client I get segfaults. The tickets do make it into the system but somewhere along the line it dumps core. Along with this, I see the error mesasge "REQADM Server Error: Unable to look up token". I haven't been able to determine which token REQADM is unable to look up. -mtw -- Matthew White District Systems Administrator Tigard/Tualatin School District 503.431.4128 |
|
From: Steve W. <st...@al...> - 2003-12-03 07:45:28
|
Tom Ivar Helbekkmo wrote:
> It occurs to me that being able to load more than one database driver
> might be a good thing. For instance, one could envisage keeping the
> ticket system in one database, while accessing another one to fetch
> existing information about users/customers/machines/whatever. It
That's an interesting idea to keep in mind. I'd like to keep each
iteration as simple as possible, but it would be a good way to develop
the code into as we go on.
> As soon as you have the API in place, I'd like to start writing a
> PostgreSQL version of the database access module. Accepting the
> limitations of a primitive database system like MySQL won't go down
> well around here... :-)
Sounds great!
--
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-03 07:31:06
|
Steve Willoughby <st...@al...> writes: > Yes, actually, I've already started writing a MySQL replacement for it. Great! :-) > Not only should this speed up REQADM and make it easier to set up, but > I'm considering ditching all the weird little support services and scripts > which keep REQADM in sync with your organization's user list, and just > document a couple of MySQL tables and say "Just do whatever you need to > do to keep these tables up to date on your end, and REQADM will read them." That seems like a very good idea. Depending on local needs, they could even be replaced by views that pull data from other databases. > The actual database code will be in one source module, and that module > (which I'm writing for MySQL) can be switched for another copy written > for Oracle, or one for Sybase, or whatever people want to do. It occurs to me that being able to load more than one database driver might be a good thing. For instance, one could envisage keeping the ticket system in one database, while accessing another one to fetch existing information about users/customers/machines/whatever. It would mean keeping some cross references out of actual queries, as in not JOINing ticket and user tables directly, but doing separate queries that expect a user ID to mean the same user in both databases. Not sure it's worth the complexity, though. As soon as you have the API in place, I'd like to start writing a PostgreSQL version of the database access module. Accepting the limitations of a primitive database system like MySQL won't go down well around here... :-) -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
|
From: Steve W. <st...@al...> - 2003-12-03 01:42:55
|
Ibrahim Khalifa wrote:
> wouldn't it be nice to keep it as database independent as
> possible? That way it would allow someone to come along in say 6 months
> and write support for another RDBMS too, and it could be incorporated
> into the main branch.
Yes, that'll be the basic approach. The main thing up front will be
moving it from a network-model DBMS + flat files to an RDBMS-only model.
The actual database code will be in one source module, and that module
(which I'm writing for MySQL) can be switched for another copy written
for Oracle, or one for Sybase, or whatever people want to do.
--
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-02 22:53:51
|
Steve Willoughby <st...@al...> writes: > Summary: > 1. reqadm-users-l mail list moved > 2. REQADM project now purely non-Intel open source development > 3. new release available for download Great news, Steve! Much thanks for your effort! > As for the state of the REQADM project itself... In 2002, Intel > formally ceased all development efforts on the project. However, > they had also previously released REQADM for Open Source > development, so the development of this project now continues in the > Open Source realm. So, if I read you correctly, the move from the Athena database to a "real" RDBMS with SQL didn't make it in time, and will be a task for the user community? Has anyone started? I'd like to a) get 1.3 up and running, and then b) start rewriting the database access code as soon as possible... -tih -- Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901 |
|
From: Ibrahim K. <ib...@to...> - 2003-12-02 22:12:58
|
On Tue, Dec 02, 2003 at 01:39:39PM -0800, Steve Willoughby wrote: Hi, > > So, if I read you correctly, the move from the Athena database to a > > "real" RDBMS with SQL didn't make it in time, and will be a task for > > the user community? Has anyone started? I'd like to a) get 1.3 up > > and running, and then b) start rewriting the database access code as > > soon as possible... > Yes, actually, I've already started writing a MySQL replacement for it. I probably should be quiet, since I'm no longer using Reqadm, due to an acquisition, and most likely won't have any time to help along with this task. But, wouldn't it be nice to keep it as database independent as possible? That way it would allow someone to come along in say 6 months and write support for another RDBMS too, and it could be incorporated into the main branch. //Ibo |
|
From: Steve W. <st...@al...> - 2003-12-02 21:50:22
|
Tom Helbekkmo wrote:
> So, if I read you correctly, the move from the Athena database to a
> "real" RDBMS with SQL didn't make it in time, and will be a task for
> the user community? Has anyone started? I'd like to a) get 1.3 up
> and running, and then b) start rewriting the database access code as
> soon as possible...
Yes, actually, I've already started writing a MySQL replacement for it.
Not only should this speed up REQADM and make it easier to set up, but
I'm considering ditching all the weird little support services and scripts
which keep REQADM in sync with your organization's user list, and just
document a couple of MySQL tables and say "Just do whatever you need to
do to keep these tables up to date on your end, and REQADM will read them."
That way, there's no reason you'd need to shut down REQADM's server for
maintenance each night, and the installation and maintenance of the
system gets even easier.
This is a somewhat involved change, though, because currently the
ticket data are stored in ASCII flat files, with a subset of their
attributes in the DBMS. In the SQL version, REQADM will store the
entire ticket data properly in database tables. This means that all
the code currently in the clients (request object) to parse out and
reconstruct that ASCII format will go away, and they'll just send and
receive ready-to-use data structures.
--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: Steve W. <st...@al...> - 2003-11-29 21:40:01
|
Summary: 1. reqadm-users-l mail list moved 2. REQADM project now purely non-Intel open source development 3. new release available for download Greetings. As you may have noticed, we moved the "reqadm-users-l" mailing list from ichips.intel.com to lists.sourceforge.net. Please use the new list address when posting to the list. Or, better yet, if you want to report a bug, request a feature, or make a general REQADM community comment, do it in the SourceForge forum provided on the project website, so we can keep volume on this list as low as possible. As for the state of the REQADM project itself... In 2002, Intel formally ceased all development efforts on the project. However, they had also previously released REQADM for Open Source development, so the development of this project now continues in the Open Source realm. *ALL* support issues, questions, etc., should be directed at the open source development team via the sourceforge site. Intel cannot and will not offer support for REQADM. (Remember, this was never an "Intel product", but a local tool used by one team of system administrators within the company.) We have gone over the code and removed the last vestiges of odd localisms which had been hardcoded, making REQADM much easier now to build elsewhere. The build process has been streamlined to something like: configure make make dist setup The distribution includes some sample reports, and some additional auxiliary tools for keeping REQADM in sync with your own user info. This now appears on the sourceforge site as "REQADM 1.3" We have established a project homepage at: http://reqadm.sourceforge.net However, this is still under development and there are some missing links on that page. For now, you can get to the main file download area, bug tracking facilities, etc., from the project URL: http://sourceforge.net/projects/reqadm/ Enjoy! --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: Steve W. <st...@q7...> - 2003-11-29 21:01:51
|
Just testing the list. |
