Installation of MySQL Database Server

.

These simple steps install and start MySQL database server on Fedora 20:

  • Install the package “community-mysql-server”: # yum -y install community-mysql-server
  • Start the daemon service: # systemctl start mysqld.service
  • Enable the daemon service: # systemctl enable mysqld.service
  • Connect to MySQL: # mysql -u root. Type Enter
  • Set the root password: mysql> set password for root@localhost=password(‘password’);

You can replace the localhost with your domain or IP address.

  • Delete anonymous users: mysql> delete from mysql.user where user=”;
  • mysql> exit

If you forgot the root password, do these:

  • # mysqld_safe –skip-grant-tables &
  • mysql> use mysql;
    mysql> update user set password=PASSWORD(“New-Password”) where User=’root’;
    mysql> flush privileges;
    mysql> quit
  • # systemctl stop mysqld
  • # systemctl start mysqld
  • # mysql -u root -p

Advertisements

Distributed Hash Table (DHT) In Structured Peer-to-Peer SIP Overlay

.

peersDistributed Hash Table (DHT) is used in structured Peer-to-Peer overlay for resource location and discovery. In SIP world, the resource can be the contact list (physical addresses) associated with an AOR (SIP/SIPS URI that points to a user on domain -virtual address of the user). The mappings between the AORs and the contact lists will be distributed amongst the peers in the SIP overlay. In this way we get a distributed registrar functionality for SIP.

There should be an interface for the DHT so it can be used without caring about the implementation and it can easily integrate with the SIP server so the server can work in P2P mode. Basically the functions that need to be implemented are: Join (join the overlay), Leave (leave the overlay), Lookup (search for a resource using the AOR as a key), and Store (store the resource). For example the lookup function works as following:

  • Using the AOR as a key to find the appropriate node/peer. The hash value of the key is used to find the node/peer ID.
  • Then the selected node/peer will do normal hash table (HT) lookup to get the value/resource/contact-list

The mappings {AOR, Contact List} can be stored persistently on disks in a key-value databases like Berkeley DB.

The IETF standards body is working on P2P-SIP. There is a working group called p2psip where you can find the internet drafts (working documents) related to P2P-SIP. For example the RELOAD (RFC [6940]) is a signaling protocol for resource location and discovery. It specifies “chord-reload” as a mandatory DHT algorithm to be implemented. The purpose of this work is distributed SIP registrar. The RELOAD works with SIP to enable the distributed SIP solution. The RELOAD can be used by other protocols and not only SIP (e.g. A Constrained Application Protocol (CoAP) usage for RELOAD: Internet Draft: draft-jimenez-p2psip-coap-reload-10).

But why P2P SIP mode. This is because in P2P:

  • There is no one point of failure.
  • Less cost: avoid having service provider (Paying) + delete nodes/peers on low demand.
  • Capacity: Adding new nodes/peers on high demand.

The peer to peer SIP overlay is very suitable to be built over Openstack cloud where the automated creation and deletion of nodes/peers is based on predefined policies. The peers are defined in an autoscaling group where they are scaled up and down based on the autoscaling policies. When a node is determined to leave the overlay based on the cloud policies, the node starts the leave process where the configuration is delivered to it from the cloud (DELETE lifecycle hook). The trigger to add (<=> join the overlay) or delete server (<=> leave the overlay) are controlled by the cloud orchestration service (the scaling policies). The policies itself are based on CPU utilization, Load,…etc.


Creative Commons License
The content of this blog is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.


Permit Root Login Into Instance Launched From Centos Official Image

Introduction

If you tried to access your instance using SSH as root:

# ssh -i PrivateKey.pem  root@Floating-IP-Address Where Flaoting-IP-Address is the flaoting IP address associated with your instance. You might get this message: “Please login as the user “centos” rather than the user “root”.” Then the connection will close.

Steps To Allow Root Access Through SSH

  • Login as the user “centos”: # ssh -i PrivateKey.pem  centos@Floating-IP-Address
  • Change to root: # sudo -s
  • Edit the file “/root/.ssh/authorized_keys” (# vi /root/.ssh/authorized_keys) and keep it only contains the key  (starts with “sh-rsa”) without the restrictions that exist at the begining of the file.
  • Open the file “/etc/ssh/sshd_config” and uncomment the line “PermitRootLogin yes”
  • Restart SSH daemon: # systemctl restart sshd

Now you can SSH as root to your instance.

Note: You need to automate the above if your servers are created/ deleted on demand and SSH public keys are inserted in servers on boot by Openstack.