How to create central YUM Repository server on CentOS step by step

How to create central YUM Repository server on CentOS

Step 1. To Install Createrepo on server

[root@repo ~]# yum -y install httpd xinetd syslinux vsftpd dhcp

Complete!

Step 2. To Create repository directory and add packages on directory

[root@repo ~]# mkdir /repos/CentOS/6.8/ -p

[root@repo ~]# createrepo –update /repos/CentOS/6.8/
Could not find valid repo at: /repos/CentOS/6.8/

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

Step 3. To Mirror using Local ISO

[root@repo /]# mount -o loop /media/sr0/ /mnt/
[root@repo /]# cp -arv /mnt/* /repos/CentOS/6.8/

Step 4. To Mirror using Online Repository

[root@repo /]# rsync -rz –progress rsync://download.nus.edu.sg/centos/6.8/

Step 5. To publish our local repository via apache

[root@repo /]# yum install httpd

[root@repo /]# ln -s /repos/CentOS/ /var/www/html/CentOS

[root@repo ]# /etc/init.d/httpd start
Starting httpd: [ OK ]

Step 6. If you need File sharing using FTP

[root@repo /]# yum install vsftpd

[root@repo /]# ln -s /repos/CentOS/ /var/ftp/pub/CentOS_ftp

[root@email CentOS]# /etc/init.d/vsftpd start
Starting vsftpd for vsftpd: [ OK ]

Step 7. To create local.repo on client systems

cd /etc/yum.repo.d/

vi local.repo

Add as follow:

[mylocalrepo]
name=Local CentOS Repo
baseurl=http://my-repo-server/CentOS/6.8
gpgcheck=0

 

How To Configure Outgoing SMTP Authentication on Zimbra 8.7

How To Configure Outgoing SMTP Authentication on Zimbra 8.7

When we need to route all outgoing mail through your ISP’s MTA, and that MTA requires that you authenticate, certain settings in postfix are required.

Required outgoing SMTP mailrelay

SMTP Relay : relayserver.server.lan
Username : relayacc@server.lan
Password : Relay@Sev
Port : 25 / 587 / 465

Let’s create a relay access file for zimbra authentication to outgoing SMTP, and create a file relay_access as follows:

# vi /opt/zimbra/conf/relay_access

relayserver.server.lan relayacc@server.lan:Relay@Sev # add this line

save and exit

Now postmap relay_access

# postmap /opt/zimbra/conf/relay_access

To enable outgoing mail for zimbra

# zmprov ms `email.server.lan` zimbraMtaSmtpSaslPasswordMaps lmdb:/opt/zimbra/conf/relay_access
# zmprov ms `email.server.lan` zimbraMtaSmtpSaslAuthEnable yes
# zmprov ms `email.server.lan` zimbraMtaSmtpCnameOverridesServername no
# zmprov ms `email.server.lan` zimbraMtaSmtpTlsSecurityLevel may
# zmprov ms `email.server.lan` zimbraMtaSmtpSaslSecurityOptions noanonymous

# zmprov ms `email.server.lan` zimbraMtaRelayHost relayserver.server.lan:587 -> The port may change it

No need reload postfix, it will automatically update within 2 minutes, change the necessary action for mx to DNS.

Note : If mails are not being delivered while checked mail.log. We need to confirm our SMTP ports like 465 or 587 because of some ISP’s not enable TLS properly. So on time change the port will as above formet mention.

That’s it 🙂

 

 

Diff. b/w RAMFS and TMPFS Mount

Diffent b/w RAMFS and TMPFS

Both can allocate part of the physical memory to be used as a partition. Once you mount the partition and start writing and reading files to the RAM, it should be faster.

1. How to mount Tmpfs

# mount -t tmpfs -o size=512M tmpfs /opt/zimbra/data/amavisd/tmp
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_email-LogVol01
18G 5.6G 12G 33% /
tmpfs 936M 72K 936M 1% /dev/shm
/dev/sda1 291M 49M 227M 18% /boot
tmpfs 512M 0 512M 0% /opt/zimbra/data/amavisd/tmp

2. How to mount Ramfs

# mount -t ramfs -o size=512M ramfs /opt/zimbra/data/amavisd/tmp
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_email-LogVol01
18G 5.6G 12G 33% /
tmpfs 936M 72K 936M 1% /dev/shm
/dev/sda1 291M 49M 227M 18% /boot
tmpfs 512M 0 512M 0% /opt/zimbra/data/amavisd/tmp

# mount
/dev/mapper/vg_email-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
tmpfs on /opt/zimbra/data/amavisd/tmp type tmpfs (rw,size=512M)

3. Ramfs vs Tmpfs

Ramfs will grow dynamically / Tmpfs will not grow dynamically
Ramfs does not use swap / Tmpfs uses swap

4. Disadvandages

Since both ramfs and tmpfs is writing to the system RAM, it would get deleted once the system gets rebooted, or crashed. So it will not help in the time of system crash.

 

How to Create Admin account with limited access

How to Create Admin account with limited access:

Create a distribution list for the admins and select the option to not receive email and hide in GAL. like zimbra-group@server.lan

To create admin user:

[zimbra@mail conf]$ zmprov ca zimbra-admin@server.lan ZimAdn@
b8a8430e-a42e-456d-9e88-0c227bc845bd

To enable distribution list the group

[zimbra@mail conf]$ zmprov modifyDistributionList zimbra-group@server.lan zimbraIsAdminGroup TRUE

[zimbra@mail conf]$ zmprov modifyAccount zimbra-admin@server.lan zimbraIsDelegatedAdminAccount TRUE

[zimbra@mail conf]$ zmprov modifyDistributionList zimbra-group@server.lan zimbraAdminConsoleUIComponents accountListView zimbraAdminConsoleUIComponents DLListView zimbraAdminConsoleUIComponents aliasListView zimbraAdminConsoleUIComponents COSListView zimbraAdminConsoleUIComponents saveSearch

 

How to Configure OpenStack Network to Enable Access to OpenStack Instances

How to Configure OpenStack Network to Enable Access to OpenStack Instances

1. To Create OpenStack networks from dashboard, first we need to create an OVS bridge and modify our physical network interface to bind as a port to OVS bridge.

[root@cloud /]# cd /etc/sysconfig/network-scripts/
[root@cloud network-scripts]# ls
1 ifdown-ovs ifup-eth ifup-sit
ifcfg-br-ex ifdown-post ifup-ib ifup-Team
ifcfg-eth0 ifdown-ppp ifup-ippp ifup-TeamPort
ifcfg-lo ifdown-routes ifup-ipv6 ifup-tunnel
ifdown ifdown-sit ifup-isdn ifup-wireless
ifdown-bnep ifdown-Team ifup-ovs init.ipv6-global
ifdown-eth ifdown-TeamPort ifup-plip network-functions
ifdown-ib ifdown-tunnel ifup-plusb network-functions-ipv6
ifdown-ippp ifup ifup-post
ifdown-ipv6 ifup-aliases ifup-ppp
ifdown-isdn ifup-bnep ifup-routes

[root@cloud network-scripts]# cp ifcfg-eth0 ifcfg-br-ex

2. To edit and modify the bridge interface (br-ex) using a text editor as illustrated below:

[root@cloud network-scripts]# vi ifcfg-br-ex
HWADDR=00:0C:29:A4:F9:49
TYPE=Ethernet
BOOTPROTO=static
IPADDR=10.100.100.123
PREFIX=24
GATEWAY=10.100.100.1
DNS1=8.8.8.8
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_PRIVACY=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=”br-ex”
UUID=4c45f763-8c4c-38d1-af88-b7e6283c652f
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999

save and exit

3. We need to do same with physical interface and make sure like as follow:

[root@cloud network-scripts]# vi ifcfg-eth0

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=no
IPV6_PEERDNS=no
IPV6_PEERROUTES=no
IPV6_FAILURE_FATAL=no
IPV6_PRIVACY=no
ONBOOT=yes
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex

save and exit

4. Restart network

[root@cloud network-scripts]# systemctl restart network.serivce

5. Then we need to do like as follow:

Login to Openstack web panel (dashboard) with admin credentials and go to Identity -> Projects -> Create Project and create a new project

Next, navigate to Identity -> Users -> Create User and create a new user by filling all the fields with the required information.

Assure that this new user has the Role assigned as a _member_ of the newly created tenant (project).

After the user has been created, log out admin from dashboard and log in with the new user in order to create two networks (internal network and external).

Navigate to Project -> Networks -> Create Network and setup the internal network

For example:

Network Name: internal
Admin State: UP
Create Subnet: checked
Subnet Name: internal
Network Address: 192.168.1.0/24
IP Version: IPv4
Gateway IP: 192.168.1.1
DHCP: Enable

Also, replace the Network Name, Subnet Name and IP addresses with your own custom settings.

Use the same steps as above to create the external network

For example:

Network Name: external
Admin State: UP
Create Subnet: checked
Subnet Name: external
Network Address: 192.168.2.0/24
IP Version: IPv4
Gateway IP: 192.168.2.1
DHCP: Enable

Then replace the Network Name, Subnet Name and IP addresses according to your own custom configurations.

we need to log in OpenStack dashboard as admin and mark the external network as External in order to be able to communicate with the bridge interface.

Thus, login with admin credentials and move to Admin -> System-> Networks, click on the external network, check the External Network box and hit on Save Changes to apply the configuration.

When done, logout from admin user and log in with the custom user again to proceed to the next step.

Finally, we need to create a router for our two networks in order to move packets back and forth. Go to Project -> Network -> Routers and hit on Create Router button. Add the following settings for the router.

Once the Router has been created you should be able to see it in the dashboard. Click on the router name, go to Interfaces tab and hit on Add Interface button and a new prompt should appear.

Select the internal subnet, leave the IP Address field blank and hit on Submit button to apply changes and after a few seconds your interface should become Active.

To verify OpenStack network settings, go to Project -> Network -> Network Topology and a network map will be presented

Now OpenStack network is now functional and ready for virtual machines.

 

 

Diff. b/w Stateful / Stateless Services for HA

What is different between stateful and stateless services for High Availability Technologies.

Stateful:

• An action typically comprises multiple requests
• Data needs to be replicated and synchronized between redundant services (to preserve state and consistency)
• For example on Openstack services for stateful  MySQL, RabbitMQ, Cinder Volume, Ceilometer center agent, Neutron L3, DHCP agents, etc.

Stateless:

• There is no dependency between requests
• No need for data replication/synchronization. Failed request may need to be restarted on a different node.
• For example on Openstack for stateless services  Nova-api, nova-conductor, glance-api, keystone-api, neutron-api, nova-scheduler, Apache web server, Cinder Scheduler, etc.