[racktables-users] Re: RackTables RPM

  • From: Colin Coe <colin.coe@xxxxxxxxx>
  • To: racktables-users@xxxxxxxxxxxxx
  • Date: Tue, 29 Sep 2009 18:39:56 +0800

Well, that took a while... :)

The rpm is in the testing repo for Fedora 10, 11 and EPEL v5.  It's
still on v0.17.4 as I'm working on the v0.17.5 package.

Included in the rpm is a script called contrib/quickinstall.sh to make
it easier for people new to RackTables to get up and going.  The paths
are Fedora/RHEL centric.  Constructive criticisms welcome.

It would be great if Fedora/RHEL users could try out the package
(remember backups!) and increase the karma of the package via
https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9797?_csrf_token=a6ae151c3e521187c5fb54e2e74be0c93b8a0112.
 If there are problems, Id appreciate it you let me know so I can
address the concerns rather than giving negative karma which will kick
the package out of Fedora/EPEL once three negative karma are received.

Thanks again

CC

On Sat, Sep 5, 2009 at 4:29 AM, Denis Ovsienko <pilot@xxxxxxxxxx> wrote:
> On Fri, 4 Sep 2009 20:48:42 +0800 Colin Coe wrote:
>
>> Quick question.
>>
>> I was testing my RPM for RackTables on a fresh machine and everything
>> seemed OK until I browsed to the URL and got this message:
>> ---
>> This Racktables installation seems to be just upgraded to version
>> 0.17.4, while the database version is 0.14.4. No user will be either
>> authenticated or shown any page until the upgrade is finished. Follow
>> this link and authenticate as administrator to finish the upgrade.
>> ---
>>
>> At this point MySQL server has just been installed and a root password
>> set but nothing else.
>>
>> Any ideas why it thinks it has a 0.14.4 version DB?
>
> Normally the version is stored in one of the tables, unless it is
> a really old database (0.14.4 or worse). This way the version check
> returns "0.14.4" for any database, which exists, but has no "Config"
> table. The real reason behind this message in a modern enviroment is
> most probably a pre-written secret.php file, which enables
> application's access to an empty database. This is not a common case,
> because the installer script normally populates the DB after it writes
> secret.php file.
>
> Perhaps, at this point the RPM shouldn't come with secret.php, but let
> the user create it.
>
>



-- 
ZFS: Just because you can, doesn't mean you should.

Other related posts: