Archive for the ‘linux’ Category


Restore >1GB database dump;

  • phpmyadmin – too slow, errors, php.ini modifications etc.
  • mysqldump – slow, errors ex. BLOB



  • create empty database, for example by phpmyadmin
  • connect to it:

mysql -u usertest -p databasetest

  • type path to db dump:

source /backup/databasetest_2017-10-01.sql



You will see progress like:

Query OK, 7146 rows affected (0.42 sec)
Records: 7146 Duplicates: 0 Warnings: 0




Correct settings for LDAPS in Zabbix.
You must type ldaps:// in Active Directory address bind.


3-node cluster has access to one disk with GFS/GFS2 filesystem.

  • node1 – offline
  • node2 – offline
  • node3 – online

Node3 waits for other nodes to connect. Unfortunately, node2 and node 3 are phisically damaged.

Cluster cannot start and mount GFS/GFS2 filesystem.
Console shows errors:

can't connect to gfs_controld: Connection refused  
can't connect to gfs_controld: Connection refused  
gfs_controld not running  
error mounting lockproto lock_dlm


gfs_controld join connect error: Connection refused
error mounting lockproto lock_dlm

Convert GFS/GFS2 cluster to work as a standalone server.
To do this we need to change superblock locking protocol of GFS/GFS2 filesystem.

Check what is current type of locking protocol:


gfs_tool sb <device> proto
gfs2_tool sb <device> proto

gfs_tool sb /dev/sdb proto
gfs2_tool sb /dev/sdb proto

Change superblock locking protocol to lock_nolock:

gfs_tool sb <device> proto lock_nolock
gfs2_tool sb <device> proto lock_nolock

gfs_tool sb /dev/sdb proto lock_nolock
gfs2_tool sb /dev/sdb proto lock_nolock

Restart cluster service or whole server. Disk should mount successfully.
Now you may start to run backup :)

To revert superblock to previous settings, lock_dml, set:

gfs_tool sb <device> proto lock_dlm
gfs2_tool sb <device> proto lock_dlm

gfs_tool sb /dev/sdb proto lock_dlm
gfs2_tool sb /dev/sdb proto lock_dlm


Helpful commands:

mount -t gfs2 /dev/sdb /mnt/storage
service cman start
service gfs2 start

Recently I bought a cheap micro (mini) adapter LAN: Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN

In Fedora 16, Linux Mint 12 was installed automatically, but still not functioning properly.

My WiFi network was not found (Authentication WPA with TKIP + sign and also without authentication), but what is weird a few other WiFi networks with WPA authentication adapter has detected. Yes, it is very strange and indicates a a problem with software.

Here’s a solution for this problem:

1. Determine model of WLAN adapter and version of OS

user@computer:  lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp.  RTL8188CUS 802.11n WLAN

user@computer:   cat /etc/issue
Linux Mint 12 Lisa

user@computer:   cat /etc/issue

2. Download latest drivers for linux from here

3. Unpack drivers

4. Install drivers typing:

change permissions to run installation script
user@computer:   chmod a+rwx   ./
run installer
user@computer:   ./

5. Restrict loading old drivers by adding at the end of file /etc/modprobe.d/blacklist.conf  line:

blacklist rtl8192cu

6. Reboot computer and enjoy :)

If you installed Google Chrome and you can not run it on the root account, receiving messages like the following:

Google Chrome can not be run as root
Please start Google Chrome as a normal user. To run as root, you must specify an alternate –user-data-dir for storage of profile information


[polish version]
Przeglądarki Google Chrome nie możesz uruchamiać jako użytkownik root.
Uruchom aplikację Google Chrome jako zwykły użytkownik. Uruchamianie jako użytkownik root wymaga podania alternatywnego katalogu –user-data-dir do przechowywania danych profilu.


Here is a solution:

  • [optional]
    root@localhost > xhost +

    Turns off acccess control (all remote hosts will have access to X server).
    o turn access control back on type xhost –
  • root@localhost > vim /usr/bin/google-chrome
    Edit in any text editor Google Chrome configuration file and find line
    exec -a “$0″ “$HERE/chrome” “$@”
    and type at the end of line -user-data-dir
    so edited line should look like this:
    exec -a “$0” “$HERE/chrome” “$@” -user-data-dir

Now you should be able to run Google Chrome with root rights. Of course, for safety reasons I would advise careful with too frequent use of applications in this way.