|
If your Linux box has multiple network interfaces (e.g. eth0, eth1 etc) and you have to deal with firewall rules, you may have to know which exact interface (local IP) is being used to reach that particular remote host. The answer is: /sbin/ip route get "target_ip"
Then you may ask, - how do I found out the "target_ip" by the host name? That's easy - use ping "target_host_name" or host "target_host_name". |
|
Encountered user not being able to login on a newly configured system. All attempts to login with seemingly right credentials were failing. The httpd error_log had records like this: user user1: authentication failure for "/": Password Mismatch
As it turned out - all users had this problem, and the users' credentials were totally fine in the Active Directory. Unfortunately my httpd-2.2 does not seem to have debug components for mod_ldap, it had been added in 2.4 (if to trust stackoverflow topic So, the easiest way was to try the ldapsearch Linux command line tool. The problem popped right up showing the problem was with binding credentials. The command line looked like this: ldapsearch -H ldap://mydc:3268 -D "CN=ldap_user,OU=LDAP Auth,dc=mydc" -s base "(ojectclass=*)"
The httpd config mapping is quite obvious: Lessons learned:
|
|
psql is handy command line tool for full control of the postgresql database. Here is quick cheat-sheet on how to navigate through a database structure, how to view databases and tables. Imagine you have to get a list tables for a certain database. Before you dive into the dark world of psql navigation, you've got to know that when browsing postgresql database expect certain hierarchy of its objects. The grand path is:
Here is how you browse postgresql with psql command line tool. Once you get into postgres database cluster with psql: Get the list of databases available with \l. To switch to a database do \c your_database. In terms of postgresql that is "connect to a database". You can also shortcut to the database by calling psql -d your_database or just psql your_database. Before you get to the list of tables you better off to get schema names (tables are members of schemas in postgresql), execute \dn. Now, finally you should be able to get the list of tables using something like this: \dt your_schema. (note the trailing dot). That is it. Quick and easy :-) |
|
If you are at old MySQL (back from 2010ish), you might find it useful:
Multi-Master Replication Manager for MySQL.
Installing and Managing Multi Master Replication Manager(MMM) for MySQL High Availability from High Availability MySQL Cookbook |
|
Basic Elastic Search commands over terminal (Command Line Interface) can be handy when Kibana or any other fancy interface is not available and you need to do a basic troubleshooting. We will use curl - to make HTTP requests from command line. In the example it is assumed you are at the same box as the Elastic Search instance. Replace localhost with your actual host name/IP if you are doing debug from a remote terminal. We also assume you are using standard Elastic Search port 9200. Replace it with your value if you tweaked it. MY_INDEX is a placeholder for whatever index you'll be working with. pretty=1 is to get nice multiline output. Get all indexes from the Elastic Search: curl http://localhost:9200/_aliases?pretty=1
Make a query to Elastic Search. In this example that's just trivial search for all "response" fields with value "200". You may caonstruct way more complex queries with lucene syntax.
curl -XGET 'http://localhost:9200/MY_INDEX/_search?q=response=200&pretty=1'
Delete a given index: curl -XDELETE 'localhost:9200/MY_INDEX/'
|
|
Python Imaging Library (PIL) enables simple yet capable support for reading and editing images with Python scripts. Installing it on RedHat - CentOS systems is super-easy: See more on the library at the official PIL website. |
|
Faced access denied error when attempting to start postgresql 9.2 with custom database path on CentOS 7: ~]$ sudo systemctl start postgresql.service ~]$ systemctl status postgresql.service The file had been actually in place and with the right permissions and all the dir permissions seemed right too. It was SELinux limiting access to the postgres database files in the non-standard location. Examining the /var/log/audit/audit.log quickly revealed that. The log had the denial record like that: type=AVC msg=audit(1437920005.070:1886): avc: denied { getattr } for pid=5732 comm="postgres" path="/var/pgsql/data/postgresql.conf" dev="dm-0" ino=779014 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file The dir listing with SELinux context had: ~]$ sudo ls -Z /var/pgsql/data
... The most secure way is to relabel corresponding files and to adjust selinux file contexts. In my case the custom location was /var/pgsql/ Initially I did relabel my db files. Since I had no log files yet, it was enough to do just: sudo sudo chcon -R system_u:object_r:postgresql_db_t:s0 /var/pgsql/ You may also have to execute chcon system_u:object_r:postgresql_log_t:s0 on whatever log files you have. Add your new location of the db and log files location's contexts to selinux fcontext. Since in my case the custom location was /var/pgsql/, - I added:
sudo semanage fcontext -a -t postgresql_db_t '/var/pgsql(/.*)?' After all this magic, postgresql was able to successfully start with the database in my custom location. If you don't have to be that secure, you may just set SELinux into permissive mode, or turn it off (not recommended). See how. Good luck :-) |