I had a fresh install of RHEL 6.6 with MySQL 5.1.73. When i tried to reset MySQL root password for MySQL, it hadn’t worked. Reason was, that mysql.user table was empty, there was no ‘root’ user created.
Following helped me to resolve the issue:
- Restart MySQL like this:
service mysqld restart --skip-grant-tables
- Enter MySQLfrom the command line (no password needed at this point)
You will see 17 rows for MySQL 4.1
You will see 37 rows for MySQL 5.0
You will see 39 rows for MySQL 5.1
You will see 42 rows for MySQL 5.5
You will have to tweak each privilege since the GRANT command does not work will skip-grant-tables is enabled
- For MySQL 5.1, you can enter a new root@localhost whose password is ‘whatever’ as follows:
DELETE FROM mysql.user WHERE user='root' AND host='localhost';
INSERT INTO mysql.user SET
Host = 'localhost',
User = 'root',
Password = PASSWORD('whatever'),
Select_priv = 'Y',
Insert_priv = 'Y',
Update_priv = 'Y',
Delete_priv = 'Y',
Create_priv = 'Y',
Drop_priv = 'Y',
Reload_priv = 'Y',
Shutdown_priv = 'Y',
Process_priv = 'Y',
File_priv = 'Y',
Grant_priv = 'Y',
References_priv = 'Y',
Index_priv = 'Y',
Alter_priv = 'Y',
Show_db_priv = 'Y',
Super_priv = 'Y',
Create_tmp_table_priv = 'Y',
Lock_tables_priv = 'Y',
Execute_priv = 'Y',
Repl_slave_priv = 'Y',
Repl_client_priv = 'Y',
Create_view_priv = 'Y',
Show_view_priv = 'Y',
Create_routine_priv = 'Y',
Alter_routine_priv = 'Y',
Create_user_priv = 'Y',
Event_priv = 'Y',
Trigger_priv = 'Y',
ssl_type = '',
ssl_cipher = '',
x509_issuer = '',
x509_subject = '',
max_questions = 0,
max_updates = 0;
- Restart MySQL
service mysqld restart
Source: Database Administrators Stack Exchange
I could connect to my account from the phone (Nokia C7) and I could also reach my account on internet, but I was not able to sign-in to my account in Nokia Suite.
Nokia Suite connects to the server account.nokia.com and auth.gfx.ms. For these servers, SSL 3 was disabled on October 15th 2014. As of today, these servers require TLS 1.0. Nokia Suite does not use TLS 1.0 but only SSL 3, because Nokia Suite uses the QT framework 4.7.4. Up to that version, the QtNetwork class QSslSocket used SSL 3 and not TLS 1.0 as default protocol.
Issue can be resolved by replacing a DLL file:
- exit the Nokia Suite via right-click in (bottom, left) Windows Notification Area (system tray)
- download this modified version of ssleay32.dll (local copy for a case it would get deleted ssleay32.zip)
- replace this file at C:\Program Files (x86)\Nokia\Nokia Suite\
Source: Nokia Support Discussions
When exiting Google Earth I’ve got the message that the myplaces.kml file could not be written down, writing to myplaces.kml.tmp instead.
Fixing is simple:
Go to the directory with settings (eg. in Windows 7 location is C:\Users\your_username\AppData\LocalLow\Google\GoogleEarth) and rename myplaces.kml.tmp to myplaces.kml.
From server perspective everything with Digital IBMer 2014 works fine. But end-users reported strange behavior: some pages were empty for them.
- Tried to reproduce the issue on test environment … issue was not reproducible, it appears in production only
- Checked IHS (Apache) access and error logs … they were clear, no issue
- Checked connection statistics (netstats) to see if we are not hitting limits … stats were OK
- Tried to reproduce issue in Firefox with Firebug … issue not reproducible, all requests made to server were returned with HTTP 200 (OK)
- Tried to reproduce issue in IE11 with Fiddler … issue reproducible, but Fiddler shown no issue, all requests were returned again with HTTP 200 (OK)
- Checked if files in cache are equal to files on server … files were OK
- Check of page in IE using F12 Developer Tools … Network tool confirmed all files were received OK, Console shown no issues, in DOM Inspector everything seemed all right
As issue was reproducible only in IE11 and not in other browsers (IE9, Firefox, Chrome, Safari), we were sure issue is not on our servers, but on the course side. We engaged developer of the course, guy from India, DOJO and browser expert. It took him about 10 minutes to identify the issue.
Problem was that somehow IBM internal servers made it to the Microsoft compatibility list, and so the production server pages were rendered in IE7 compatibility mode. And this caused Framework malfunction. Helpdesk was instructed to suggest to users to turn of both checkboxes in Compatibility View settings and make sure ibm.com is not listed within Compatibility Mode Websites, what resolved the issue.
Po instalaci WordPressu s novou šablonou Twenty Fourteen jsem narazil na problém, že se slova s diakritikou zobrazovaly špatně. Na vině je v šabloně použitý font Lato, který nepodporuje rozšířenou latinku (Latin Extended), což je pro správné zobrazování češtiny třeba.
Aby vše fungovalo jak má, je nutné nahradit tento font jiným, Latin Extended podporujícím. Já se po krátkém průzkumu rozhodl pro Open Sans, který je dostupný přes Google Fonts.
K tomu stačilo jen dle návodu How to Create a WordPress Child Theme vytvořit “podtéma”, které přejímá všechny vlastnosti originálního Twenty Fourteen (takže budoucí aktualizace nebudou mít na úpravu vliv), toto nainstalovat do WordPressu, a bylo hotovo.