Cannot login to http://hda for first time
After fresh install of Amahi 8 on Fedora 21 I can't login to http://hda.
I can reach this page from client box and I'm presented an "Amahi initialization" form with Username, Password and Password confirmation. When I enter the data and submit the form I'm taken to a page that says:
The Dashboard has encountered an exception!
Woopsie. Sorry about that!
It could be due to a bug, or very low memory, or very low disk in the root (/) partition.
If your disk or memory are not critical, it's likely a bug.
If this persists, please file a bug report with as much detail as you can.
You will be redirected to a debug page with more information shortly.
Still, after a while I'm taken to the start page again - not to the debug.
I checked and:
df -h says I have free 46G on / partition.
free -h says I have 1.2G free memory.
I used standard (automatic) partitioning on cleared disk and minimal F21 installation. During installation I created one user with admin rights and the root wasn't given a password. I switched off the router's DHCP and HDA is able to browse the Internet (I installed
links). It is also visible as "running" from amahi.org/users control panel. I'm connecting to HDA box from Ubuntu client box using WiFi set to DHCP. From client I'm able to access both the HDA's console and Internet.
I've found a closed bug #1599 that appears to cover my situation but sadly is not fixed. I followed instruction there and checked /var/hda/platform/html/log/production.log (I fpasted
tail -200 to http://ur1.ca/nxmu2 ). It seems that problem is caused by "invalid" character in my last name, that MySQL tries to insert into "users" table. My name is Marcin Pa?dziora and there is a problem with this "?" :)
#1 Updated by cpg almost 5 years ago
- Status changed from New to Assigned
- Assignee set to cpg
we think this is related to #878, which was not completed successfully. though changing default character sets and collation could break a lot of things in very subtle ways.
for the benefit of searchability, the actual error is this:
ActiveRecord::StatementInvalid (Mysql2::Error: Incorrect string value: '\xC5\xBAdzio...' for column 'name' at row 1: INSERT INTO `users` (`login`, `name`, `password_salt`, `crypted_password`, `persistence_token`, `admin`, `login_count`, `current_login_at`, `current_login_ip`, `last_request_at`, `created_at`, `updated_at`) VALUES ('forseti', 'Marcin Pa?dziora', 'aS2OlOPZNorZK5upvzhV', 'e35dc62105a83396b765f92ed956205d5c0455aed7748d2450cbeb75d42e6d9ba9b87b549562f1afc995bab3cbb098e9e0b71e0c105f75020f88bf60a8a77dc1', 'a5493b4b01cc3666212a0bf1889fbf6afccbc3c348a0705b6d14952c9d5fc0d9bf7f7c0c0fc898ab1e402a13f5f52356d49fabf0fcba63e4eeca66bb24904aea', 1, 1, '2015-10-06 21:25:30', '192.168.8.191', '2015-10-06 21:25:30', '2015-10-06 21:25:30', '2015-10-06 21:25:30')):
as a work-around, as the author points out in the forum post, it's a matter of changing the name to the username in question:
usermod -c "New Name" username
one alternative that may work for this for the next version of amahi is to default all databases and all tables to utf8_unicode_ci collation.
this is something that could break some number of web apps and we'd have to test it in regression.
a work-around to do this could be to do this in the mysql console ... but please note that this is dangerous!:
ALTER DATABASE hda_production CHARACTER SET utf8 COLLATE utf8_unicode_ci; USE hda_production; ALTER TABLE users CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
but this has not been tested.
the proper fix is to set defaults upon initialization of mysql in each HDA.
#2 Updated by forseti almost 5 years ago
Wouldn't the utf8mb4 be better than just utf8?
See this document: http://ashleyangell.com/2014/04/mysqls-utf8-isnt-really-utf8-and-how-to-properly-support-unicode/ for example.
#3 Updated by cpg almost 5 years ago
It could well be. There are a lot of opinions. While researching, someone said it's better to use utf8_general_ci because in general, utf8_general_ci is faster than utf8_unicode_ci, but less correct.
I for one do not understand the nuisances here. But I do know that it could easily break some webapps in some subtle ways, because we have occasionally seen this. Since I am using mainstream "defaults" in the US, I live in happy bliss, ignoring how the rest of the world does things and how they matter to them.
For instance, some unicode characters are stored as more than one byte and some apps may see a length of a field as one greater than it is (or one smaller), and it could crash things, strange as it may sound.
For me, we should change defaults to a best-guesstimate that will support this, but then test with a regression in our testing system. This may take a little bit of time to sort out, unfortunately.
Also available in: Atom