[freeside-users] freeside-adduser -g 1 fs_queue errors

Brendon Colby brendoncolby at gmail.com
Tue Feb 16 17:11:56 PST 2010


Greetings:

There's a posting in the forums titled "freeside-adduser -g 1 fs_queue
errors" that I tried replying to, but for some reason when I attempt
to register, it says my e-mail has been banned?! I don't know how that
could be, since I'm new to Freeside. Anyway, I don't want my hard work
to go to waste, so I'm going to post the fix to that here.

I'm running Debian 5. I installed what I could of the pre-reqs out of
the standard Debian repos, and opted to install the Freeside source
packages. I compiled a list of the stated Perl module requirements and
tested if each one was installed (perhaps an included script to do
this would help? Like RT has...) Everything seemed good.

Then I su-ed to freeside and ran the setup command:

freeside-setup -d domain.com

and got all the Postgres NOTICE output, and this:

NO CONFIGURATION TABLE FOUND at /usr/local/share/perl/5.10.0/FS/UID.pm line 131.
Can't open /usr/tmp/conf.confnum: No such file or directory at
/usr/local/share/perl/5.10.0/FS/Record.pm line 1878

It appears the "NO CONFIGURATION TABLE FOUND" messages are just
warnings. The error that made it die appears to be the "Can't open
/usr/tmp..." error. I ignored this thinking it was all just warnings,
and tried to run "freeside-adduser -g 1 fs_queue", which produced this
output:

[tons of NO CONFIGURATION messages omitted]
NO CONFIGURATION RECORDS FOUND -- USING COMPATIBILITY MODE at
/usr/local/share/perl/5.10.0/FS/TicketSystem.pm line 10
can't parse access_user.usernum default value for sequence name:  at
/usr/local/bin/freeside-adduser line 69.

After doing a bunch of troubleshooting, I just decided to start over
and check everything. Once I got to the setup command again, I became
suspicious that that wasn't really finishing properly, so I decided to
just try creating /usr/tmp, chmod'ing it to 777, and re-running the
setup command (looks like this can be deleted after setup completes).
This lead to another database specific error. I don't have it
recorded, but it was something about an issue with the data in one of
the columns it was trying to insert. I believe it explicitly said
something about the locale.

I think the default and recommended locale now on Debian systems is
UTF-8, therefore the Postgres DB was init-ed with this locale. The
"createdb -E LATIN1 freeside" command failed because you can't create
a database with a locale that's different than the system default
locale, so I just used UTF-8 thinking that it would be fine. I was
wrong. The freeside data that gets inserted when freeside-setup is run
is apparently incompatible with UTF-8 encoding.

So, I changed the Debian system locale by running "dpkg-reconfigure
locales", enabling the "en_US ISO-8859-1" locale, and making it the
default (think I even rebooted too, not sure if this is necessary). I
verified that the proper locale was default by running "locale -a":

C
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8
POSIX

Then I had to re-init the Postgres database:


!!!WARNING: THIS WILL WIPE OUT YOUR POSTGRES DATA :WARNING!!!


(become root)
/etc/init.d/postgresql-8.3 stop
mv /var/lib/postgresql /var/lib/postgresql.old
mkdir -p /var/lib/postgresql/8.3/main
chown postgres:postgres /var/lib/postgresql
su - postgres
/usr/lib/postgresql/8.3/bin/initdb -D /var/lib/postgresql/8.3/main
ln -s /etc/postgresql-common/root.crt /var/lib/postgresql/8.3/main/root.crt
ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem
/var/lib/postgresql/8.3/main/server.crt
ln -s /etc/ssl/private/ssl-cert-snakeoil.key
/var/lib/postgresql/8.3/main/server.key
/etc/init.d/postgresql-8.3 start

This will initialize the DB with the new locale. This works of course
if you have nothing else running within this instance of Postgres. I'm
not sure how to change the locale otherwise. I also had to re-create
the RT tables because I'm running with RT integration.

Then I ran the "createdb -E LATIN1 freeside" command, which succeeded
this time, then the "freeside-setup -d domain.com" which also
succeeded. Finally, I could run the "freeside-adduser -g 1 fs_queue"
commands without errors, and get logged into the Freeside site. It
appears that when everything is setup correctly, freeside-adduser
produces NO OUTPUT. I was then able to proceed with the user creation,
and getting logged into the site.

I think I've covered everything. With UTF-8 being Debian default,
others may run into this in the future. I hope this helps!

Brendon


More information about the freeside-users mailing list