4.1.2 Import from 3.6.7 causes rdairplay to have unknown exit password

[paulk-2]

After importing database from 3.6.7, rdairplay would not exit, requesting and rejecting the exit password. Database version updated from 347 to 371, then created new host based on previous host database. Imported database had no password set for rdairplay. Setting the password using RDAdmin had no effect, either to define a password or delete it.

Found that the RDAIRPLAY table had two entries for previous host (z1), but no new entry for new host (z2), so rdairplay never found a password for new/current host (z2).

| ID | STATION
| 12 | z1
| 13 | z1

I changed one of the old host entries to the new host name, then set the EXIT_PASSWORD to null, and rdairplay exited normally.

update RDAIRPLAY set STATION='z2' where ID='13'; update RDAIRPLAY set EXIT_PASSWORD=null where STATION='z2';

| ID | STATION
| 12 | z1
| 13 | z2

If this correction is not made before deleting the old host, then both old hosts (z1's) will be deleted from the RDAIRPLAY table and nothing left to modify for the current host (z2).

[ElvishArtisan]

Sounds like some corruption in the original database that got propagated and (as is often the case) amplified in the process. Do you have a copy of that original DB still around? I'd like to analyze what exactly happened.

[paulk-2]

I hope this is the part of the export from 3.6.7 you're looking for. It shows 2 entries for z1 (one with a * star; don't know what that means) and each with a password, yet in 3.6.7, it exits without password. and Z1 shows up only once in rdadmin.

As a workaround, I guess I could manually delete the extra z1 and the password, then import.

Perhaps an opportunity in 4.1.2 import to filter duplicate hosts?

When this (presumably invalid) password is imported to 4.1.2, it cannot be cleared or changed. I believe this is due to the lack of a radairplay table. steps to re-create password that cannot be cleared or changed:

1. import 3.6.7 with duplicate z1's
2. create z2 based on z1
3. delete z1 (which deletes both) now, you have z1 tables except for rdairplay

DROP TABLE IF EXISTS RDAIRPLAY; /!40101 SET @saved_cs_client = @@character_set_client /; /!40101 SET character_set_client = utf8 /; CREATE TABLE RDAIRPLAY ( ID int(11) NOT NULL AUTO_INCREMENT, STATION varchar(64) NOT NULL, INSTANCE int(10) unsigned NOT NULL, SEGUE_LENGTH int(11) DEFAULT 250, TRANS_LENGTH int(11) DEFAULT 50, LOG_MODE_STYLE int(11) DEFAULT 0, PIE_COUNT_LENGTH int(11) DEFAULT 15000, PIE_COUNT_ENDPOINT int(11) DEFAULT 0, CHECK_TIMESYNC enum('N','Y') DEFAULT 'N', STATION_PANELS int(11) DEFAULT 3, USER_PANELS int(11) DEFAULT 3, SHOW_AUX_1 enum('N','Y') DEFAULT 'Y', SHOW_AUX_2 enum('N','Y') DEFAULT 'Y', CLEAR_FILTER enum('N','Y') DEFAULT 'N', DEFAULT_TRANS_TYPE int(11) DEFAULT 0, BAR_ACTION int(10) unsigned DEFAULT 0, FLASH_PANEL enum('N','Y') DEFAULT 'N', PANEL_PAUSE_ENABLED enum('N','Y') DEFAULT 'N', BUTTON_LABEL_TEMPLATE varchar(32) DEFAULT '%t', PAUSE_ENABLED enum('N','Y') DEFAULT NULL, DEFAULT_SERVICE varchar(10) DEFAULT NULL, HOUR_SELECTOR_ENABLED enum('N','Y') DEFAULT 'N', TITLE_TEMPLATE varchar(64) DEFAULT '%t', ARTIST_TEMPLATE varchar(64) DEFAULT '%a', OUTCUE_TEMPLATE varchar(64) DEFAULT '%o', DESCRIPTION_TEMPLATE varchar(64) DEFAULT '%i', EXIT_CODE int(11) DEFAULT 0, VIRTUAL_EXIT_CODE int(11) DEFAULT 0, EXIT_PASSWORD varchar(41) DEFAULT NULL, SKIN_PATH varchar(191) DEFAULT '/usr/share/pixmaps/rivendell/rdairplay_skin.png', SHOW_COUNTERS enum('N','Y') DEFAULT 'N', AUDITION_PREROLL int(11) DEFAULT 10000, PRIMARY KEY (ID), KEY STATION_IDX (STATION,INSTANCE) ) ENGINE=MyISAM AUTO_INCREMENT=17 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; /!40101 SET character_set_client = @saved_cs_client /;

-- -- Dumping data for table RDAIRPLAY

LOCK TABLES RDAIRPLAY WRITE; /!40000 ALTER TABLE RDAIRPLAY DISABLE KEYS /; INSERT INTO RDAIRPLAY VALUES (14,'pi3',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t',NULL,NULL,'N','%t','%a','%o','%i',0,1,NULL,'/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (16,'pi1',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','','','N','%t','%a','%o','%i',0,1,'','/usr/share/pixmaps/rivendell/rdairplay_skin.png','',10000), (9,'wzig.localdomain',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','Production','N','%t','%a','%o','%i',0,0,'','/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (10,'pi2',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','Production','N','%t','%a','%o','%i',0,0,'','/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (11,'pauls-server4',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','Production','N','%t','%a','%o','%i',0,1,'','/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (12,'z1',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','','N','%t','%a','%o','%i',1,1,'*2A493EB71E6681D2DB6376FE393CBB8099579491','/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (13,'z1*',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','','N','%t','%a','%o','%i',1,1,'2A493EB71E6681D2DB6376FE393CBB8099579491*','/usr/share/pixmaps/rivendell/rdairplay_skin.png','N',10000), (15,'pi3',0,250,50,0,15000,0,'N',3,3,'Y','Y','N',0,0,'N','N','%t','N','Production','N','%t','%a','%o','%i',0,1,'','/usr/share/pixmaps/rivendell/rdairplay_skin.png','',10000); /!40000 ALTER TABLE RDAIRPLAY ENABLE KEYS */; UNLOCK TABLES;

[ElvishArtisan]

That all looks to be in order. Those password values are stored as SHA1 hashes, converted to hexidecimal strings, which those look to be.

'z1' and 'z1' are completely different strings. The universal replacement character in SQL is %, not ```, so those are two completely different host entries as far as the RDBMS is concerned. (*``` is not a valid hostname character so far as the host resolver library is concerned, but that's a different issue).

Try the following test: pop open a shell and do:

echo "<passwd>" | sha1sum

where <passwd> is the exit password for the 'z1' host. You should get back the SHA1 hash for the password. Does it match the value in the table dump (case-insensitive)?

[paulk-2]

The password does not match the hash.

I would like to focus on "z1*". It does not show up in rdadmin in either 3.6.7 or 4.1.2, but it's in the database (above) . It should not be there and never existed as far as a gui user is concerned. I don't know how it got there and perhaps is a clue that something else is going on in host management of 3.6.7 and hope it doesn't propagate to 4.1.2

If you import to 4.1.2, create a new z2 based on z1, then delete z1, it deletes all host information for the rdairplay table. It doesn't create z2 data in the rdairplay table. There is no password to check. There is no error that the data is missing.

If no one else is having these issues, we can set this aside because I have workarounds. Was hoping to help others with this info.

Thank you for your help!

[ElvishArtisan]

Circling back around to this after a few weeks...

It can be very difficult to determine where database corruption originated. Often it is from earlier Rivendell versions (the ones prior to 3.x were particularly prone to this problem); sometimes it can be introduced due to system problems (e.g. hard shutdowns) or errors introduced during SQL dumps/restores.

Your 'deletes all host information' report sounds alarming. If you've still got a copy of that DB around that you wouldn't mind sharing, I'd like to get to the bottom of that one.

[paulk-2]

I'll locate a copy.

Meanwhile, the key appears to be the two entries for z1 when there should only be one. The one with the star doesn't show up. Perhaps you can re-create this by adding a second entry for a host (based on the original) with a star at the end like 'z1*'.

Only one of the two should display in rdadmin. now create z2 based on z1, then delete z1. then look for rdairplay data on z2. it will be missing.