Problem migrating from 1.1.7 to 1.4

[dsipe]

Hello,

I've just tested the brand new 1.4 in a test environment.
Here's the different steps i used to migrate :

1) backup my zabbix mysql database with mysqldump
2) transfert the backup file to my zabbix 1.4 test server
3) create a fresh zabbix database [ mysqladmin create zabbix ]
4) restore the 1.1.7 database [ mysql zabbix < data.sql ]
5) upgrade the database to 1.4 with patch.sql in upgrade dir

6) then launch the zabbix gui and try to access/login : that's ok with my admin account

=> BUT admin has NO access to the configuration tab!!!!

[abi]

hi!

i can reproduce this issue!

Ive done a plain installation with zabbix 1.1.7 and then logged into the
web frontend - Configure tab is still there.

then ive upgraded the Database to 1.4 and then the frontend too,
the configure tab is missing after logging in as admin.

Calling config.php directly:

[ERROR: No permissions !]

the Frontend howver shows im logged in as admin:

Connected as 'Admin'

[richlv]

you should manually change user type in the db for admin user to "3".
why this isn't done by patch.sql, i have no idea

[abi]

hm.. i think there are more problems. Its also like users_groups is filled
after a fresh installation, but gets emptied after an upgrade:

plain 1.4 installation:

mysql> select * from users_groups;
+----+----------+--------+
| id | usrgrpid | userid |
+----+----------+--------+
|  1 |        7 |      1 | 
|  2 |        8 |      2 | 
+----+----------+--------+
2 rows in set (0.00 sec)

same table, upgrade 1.1.7 to 1.4:

mysql> select * from users_groups;
Empty set (0.00 sec)

updating the User Type from 1 to 3 does indeed help, the configure
tab shows up. Im just curious if thats the only problem ..

[richlv]

user and group management got changed in 1.4.
whether what you are seeing is ok, i don't know

unfortunately, i also don't have any 1.4 installation right now.

[abi]

ah found the error:

update users_tmp set type=3 where name='Admin';
                                ^^^^^^^^^^
drop table users;

i think it should be where alias='Admin'.. diff

thats not safe anyway because the alias can be edited from
the frontend aswell. Maybe they should include some smarter select
statement which gets the person with admin rights by the ids or something.

this may break on each installation which renamed the alias for the admin
...gosh

rought fix:

--- 1:1.4       2007-05-29 14:53:30.000000000 +0200
+++ patched     2007-06-01 17:15:40.000000000 +0200
@@ -971,7 +971,7 @@
 CREATE INDEX users_1 on users_tmp (alias);
 
 insert into users_tmp select userid,alias,name,surname,passwd,url,autologout,lang,refresh,1 from users;
-update users_tmp set type=3 where name='Admin';
+update users_tmp set type=3 where alias='Admin';
 drop table users;
 alter table users_tmp rename users;
 CREATE TABLE usrgrp_tmp (

or even better.. use where userid=1, that would work at least for *most*
of the upgrades.

the name column has 'Zabbix' in it, not admin with 1.1.7:

mysql> select * from users;
+--------+-------+---------+---------------+----------------------------------+-----+------------+-------+---------+------+
| userid | alias | name    | surname       | passwd                           | url | autologout | lang  | refresh | type |
+--------+-------+---------+---------------+----------------------------------+-----+------------+-------+---------+------+
|      1 | Admin | Zabbix  | Administrator | d41d8cd98f00b204e9800998ecf8427e |     |        900 | en_gb |      30 |    3 | 
|      2 | guest | Default | User          | d41d8cd98f00b204e9800998ecf8427e |     |        900 | en_gb |      30 |    1 | 
+--------+-------+---------+---------------+----------------------------------+-----+------------+-------+---------+------+
2 rows in set (0.00 sec)

[abi]

anyone? I think this is a rather stupid bug that should be fixed in
1.4.1 in order to allow smooth upgrades

[dsipe]

Same thing with maps ! all the one that've created have simply dissapeared during the upgrade process....

very buggy upgrade.

This part has to be a nice piece to allow the good migration from 1.1.x to 1.4.x
That's a major part of Zabbix 1.4 !

[glut0r]

anyone? I think this is a rather stupid bug that should be fixed in
1.4.1 in order to allow smooth upgrades

Agree. It's neccessary for zabbix to upgrade. I vote for assimilation of the fix you provided . Anyway , I'm sure you applied it in debian package, so Debian users won't hit this problem

[abi]

Agree. It's neccessary for zabbix to upgrade. I vote for assimilation of the fix you provided . Anyway , I'm sure you applied it in debian package, so Debian users won't hit this problem

i wont upload 1.4 to debian as IMHO its too buggy. Maybe 1.4.1 will go into
the archive. I prefer having a old zabbix version there instead of broken
upgrades and users complaining.

[Alexei]

FYI Two issues with upgrade scripts were fixed and reported in a different thread:

- permissions of Admin (alist must be used instead of name!)
- linkage of applications

[tronite]

Hello,

I've just tested the brand new 1.4 in a test environment.
Here's the different steps i used to migrate :

1) backup my zabbix mysql database with mysqldump
2) transfert the backup file to my zabbix 1.4 test server
3) create a fresh zabbix database [ mysqladmin create zabbix ]
4) restore the 1.1.7 database [ mysql zabbix < data.sql ]
5) upgrade the database to 1.4 with patch.sql in upgrade dir

6) then launch the zabbix gui and try to access/login : that's ok with my admin account

=> BUT admin has NO access to the configuration tab!!!!

Sounds right to me, unless maybe you missed one of the steps you have mentioned?

[tronite]

I don't understand why you won't just wipe the old one out and just do a fresh install?

[dagof]

The new table 'rights' drops all the users upgrading from 1.1.4. I lost all the users and have to create it again by hand, and assign all the permissions, homepages, medias..

Why is the insert commented in the patch.sql file?

CREATE TABLE rights_tmp (
        rightid         bigint unsigned         DEFAULT '0'     NOT NULL,
        groupid         bigint unsigned         DEFAULT '0'     NOT NULL,
        type            integer         DEFAULT '0'     NOT NULL,
        permission              integer         DEFAULT '0'     NOT NULL,
        id              bigint unsigned                 ,
        PRIMARY KEY (rightid)
) ENGINE=InnoDB;
CREATE INDEX rights_1 on rights_tmp (groupid);

--insert into rights_tmp select * from rights;
drop table rights;
alter table rights_tmp rename rights;

[Alexei]

From the manual:

User permissions of per-element level are no longer supported. It has been replaced by new user permission schema.

In other words, new permissions are not compatible with old schema, the data cannot be converted.