24 Temmuz 2013 Çarşamba

Sunucu adını değiştirme





Merhabalar,

Centos üzerinde sunucunun ismini (hostname) değiştirmek bilmeyenler için zordur. Aslında çok basit.Aşaığdaki dosyada localhost yazan yeri istediğimiz(türkçe karakter olmadan) isimle değiştiriyoruz. Ve sunucu yerniden başlatıyoruz.


vi /etc/sysconfig/network  #eski ismini değiştiriyoruz.

Ayrıca

vi /etc/hosts     #dosyasında eski adıyla ilgili alanları değiştiriyoruz.
127.0.0.1 <HOSTNAME.example.org> <HOSTNAME> localhost
::1 <HOSTNAME.example.org> <HOSTNAME> localhost
172.20.31.155 <HOSTNAME.example.org> <HOSTNAME> localhost

init 6  #shutdown -r now  ile aynı
:) 

 Peki Solaris de durum nedir?


Aşağıdaki dosyalarda tüm eski hostname adını değiştiriyoruz.


/etc/nodename
/etc/hostname.*interface
/etc/inet/hosts
/etc/inet/ipnodes



Ve son olarakda /var/carsh isimli klasörün adını değiştiriyoruz.
 

and rename directory under /var/crash

# cd /var/crash
# mv oldname newname

then reboot the server.





23 Temmuz 2013 Salı

snmp istek logunu kapatmak


snmp istek logunu kapatmak


Merhabalar,
Bazı sunucularda sunucu üzerine gelen her snmp isteklerini logladığınızı görürsünüz. Buda /var/log/messages dosyasının dolamasına hatta syslog kullanıyorsanız gereğinden fazla log attığını görürsünüz. Peki bu info mesajları nasıl kapatabiliriz sorunusu aradım. Çözüm basit. Bulduğum sayfanın orjinalinide ekliyorum.

vi /etc/sysconfig/snmpd.options   

 #aşağıda yazana benzer bir ifade bulacaksınız.sadece başındaki -LS0-4d kısmını benzetin. burda 0 ile 4 arasındakileri logla diyor.

 ... OPTIONS="-LS0-4d -Lf /var/log/snmpd.log -p /var/run/snmpd.pid -a" ...
Son olarak
service snmpd restart

 

 

(RHEL) HOWTO stop snmpd spamming /var/log/messages

Jump to: navigation, search

Contents

Introduction

The default installation of net-snmp package comes with a default configuration which cause snmpd to log at debug level within /var/log/messages. When using monitoring systems which make snmp requests every 5 minutes, it spams totally /var/log/messages with messages like:
Command: content of /var/log/messages
# tail /var/log/messages
...
Jan 23 11:10:30 sv0143 snmpd[3968]: Received SNMP packet(s) from UDP: [192.168.0.2]:54579
Jan 23 11:10:30 sv0143 snmpd[3968]: Connection from UDP: [192.168.0.3]:50596
Jan 23 11:10:30 sv0143 snmpd[3968]: Received SNMP packet(s) from UDP: [192.168.0.3]:50596
Jan 23 11:10:30 sv0143 snmpd[3968]: Connection from UDP: [192.168.0.3]:50596
Jan 23 11:10:30 sv0143 snmpd[3968]: last message repeated 8 times
This annoying behavior can be corrected by reconfiguring the snmpd daemon to log within its own files and to log on only errors to /var/log/messages.

Reconfigure snmpd

To change the way snmpd is logging, it needs to be reconfigured as follow. As root, open the file /etc/sysconfig/snmpd.options using vi:
Command: editing /etc/sysconfig/snmpd.options
# vi /etc/sysconfig/snmpd.options
Add the following line:
Config File: /etc/sysconfig/snmpd.options
...
OPTIONS="-LS0-4d -Lf /var/log/snmpd.log -p /var/run/snmpd.pid -a" 
...
Which means:
  • -LS0-4d : logging only log levels from 0 to 4 to syslog. Those levels are described below:
    • 0 or ! for LOG_EMERG,
    • 1 or a for LOG_ALERT,
    • 2 or c for LOG_CRIT,
    • 3 or e for LOG_ERR,
    • 4 or w for LOG_WARNING,
    • 5 or n for LOG_NOTICE,
    • 6 or i for LOG_INFO,
    • 7 or d for LOG_DEBUG.
  • -Lf /var/log/snmpd.log: logging everything to /var/log/snmpd.log
Then restart the snmpd service using:
Command: restarting snmpd
# service snmpd restart

Enhance log rotation

To be sure that the new log file is rotated as wanted, check the file "/etc/logrotate.d/snmpd":
Command: editing /etc/sysconfig/snmpd.options
# vi /etc/logrotate.d/snmpd
In this case, the rotate 52 and compress will be added in the default configuration file to save an history of 52 weeks of compressed logs.
Config File: /etc/logrotate.d/snmpd
  /var/log/snmpd.log {
    rotate 52
    compress
    notifempty
    missingok
    postrotate
      /bin/kill -HUP `cat /var/run/snmpd.pid 2> /dev/null` 2> /dev/null || true
    endscript
  }
Note Note: Adding rotate 52 and compress to /etc/logrotate.d/snmpd is needed only if it was not defined globally in /etc/logrotate.conf

External Links

9 Temmuz 2013 Salı

Redhat OS yum icin centos deposu ekleme ve proxy üzerinden internete çıkarma

Centos deposu oluşturuyoruz:

vi /etc/yum.repos.d/centos.repo

[centos]
name=CentOS $releasever - $basearch
baseurl=http://ftp.heanet.ie/pub/centos/5/os/$basearch/
enabled=1
gpgcheck=0


cat /etc/redhat-release

6 ise

[centos]
name=CentOS $releasever - $basearch
baseurl=http://ftp.heanet.ie/pub/centos/6/os/$basearch/
enabled=1
gpgcheck=0



--------------------------------------------------------------------------------------------------------------------------

Yum için Proxy Ayarı:


vi /etc/yum.conf

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release
proxy=http://192.168.15.196:8080

#  This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
#  It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d












5 Temmuz 2013 Cuma

SSH ile şifresiz login olma RSA Public key (2)


Merhabalar,

bir önceki yazımda SecureCRT ile oluşturduğum keylerin çalışmamasının sebebini öğrendim.

Yazının orgilan yeri :
http://www.ipsure.com/blog-tr/2010/ssh-public-key-rsa-ile-kimlik-denetimi-ve-ssh-tunneling-bolum-1/



İlk önce public-private anahtar çifti oluşturmalıyız. Bunun için aynı zamanda SSH sunucusuna bağlantı gerçekleştirirken yararlanacağımız SecureCRT terminal emulation yazılımını kullanacağız. Dilerseniz PuTTY gibi ücretsiz bir yazılımı da tercih edebilirsiniz.
Aşağıdaki gösterildiği şekilde anahtar oluşturma sihirbazını çalıştırarak public anahtar tipini RSA olarak seçiyoruz.



Private anahtarın sadece istemci tarafında bulundurulacak olması dolayısıyla her ne kadar bu anahtara ilişkin şifre belirleme işlemi opsiyonel olsada, özellikle private anahtarın kendisine izinsiz fiziksel erişim ve dolayısıyla da bu anahtarın erişim yetkisi bulunan sistemlere uzaktan erişim ihtimaline karşı güvenilirliğini sağlamak anlamında mutlaka bir şifre verilmesi ve bu şifre olmaksızın kullanılmasının önlenmesi son derece önemlidir. Bunun ötesinde özellikle ciddi uygulamalarda, verilecek olan şifrenin güvenilir şifre belirlemek için bilinen genel kriterler doğrultusunda; kullanıcı ismi, isim – soyad, doğum günü, adres /coğrafi lokasyon gibi kişisel bilgiler, sözlük kelimeleri, tekrarlama ve ardaşık karakterler içermeyen, rakam + sembol + büyük ve küçük harf kombinasyonu ile ve mümkün olduğunca yüksek entropy değerine sahip olacak uzunlukta (~ min. 12 karakter) seçilmesi önerilir.

Anahtar uzunluğumuzu 2048 bit olarak belirliyoruz.

Anahtarın oluşturulabilmesi için gereken rastlantısal girişi sağlayabilmek üzere ilk bar dolana dek mouse’umuzu pencere içerisinde rastgele hareket ettiriyor ve daha sonra anahtarın oluşturulması işleminin tamamlanmasını bekliyoruz.

SSH bağlantısı gerçekleştirmek istediğimiz sunucuda OpenSSH uygulaması çalışmakta ise anahtar formatını “OpenSSH Key format” olarak seçiyoruz ve anahtar çiftine verilecek isim ile birlikte kaydedileceği klasörü belirtiyoruz. Eğer format seçeneğinin bulunmadığı SecureCRT’nin eski bir versiyonunu (Ör: version 5.2) kullanmaktaysanız ya da bu uygulamayı gerçekleştirdiğiniz emulation yazılımı, oluşturulan anahtarları OpenSSH formatına çevirme özelliği içermiyorsa standart formatta anahtar oluşturarak dönüştürme işlemini SSH sunucusu üzerinde kendimiz manüel olarak gerçekleştirebiliriz. Bu ayrıntıya bir sonraki adımda, sunucu tarafındaki yapılandırmadan bahsederken değineceğim.

Sihirbaz yönergelerini tamamladığımızda anahtar çiftimiz belirtmiş olduğumuz lokasyona kaydedilmiş olacaktır. Şimdi sunucu tarafında gerçekleştirilmesi gereken yapılandırmaya geçebiliriz. Bunun için ilk önce public anahtarımız olan Identity.pub’ı güvenilir herhangi bir yöntemle sunucumuzdaki home klasörümüze transfer etmeliyiz. Alternatif olarak lokalde notepad ile açtığımız anahtar dosyası içeriğini sunucuda aynı isimle yaratacağımız dosya içerisine aşağıda gösterildiği şekilde manüel yapıştırabiliriz;

STANDART ANAHTAR FORMATINDA SADECE VURGULANAN ANAHTAR VERİSİ KISMINI:
---- BEGIN SSH2 PUBLIC KEY ----
Subject: Sezgin Bayrak
Comment: "sbayrak@SBMobile"
ModBitSize: 2048
AEQAB3NzsC1yc2EcA8ADAQABAA5BAQDJrOQ7BkfG9NuWqU4nAK6W5/UsDu6bLy8Y
g9IxfbE/lc7QjA9p9T8aGAG03JSLJWSr4rCflm8VUsqSkh24XxyWx5829OD3OVOO
1tbDQLaF84LefC5k6eLtOsBniLlh5DRoLx4YUZtzaeGHd5EWgINSDK22VCIonLTZ
r4h6dDmp6Gn3aHZkAP5mQwhi/lXV3Ys5BaefyVkulpXCbaprs/jOMw5TyWUrsm4S
4Gjluoxc/OIAD5Sc6UMTVgj438JxwVbDfgNbERAzvpe+sccTREqZ/Q9Z8hFqc1FB
u+G+OkstH0/ZVGxLxOfeAA6FpCvsYjCFe39cDFEoa4gJu/SLXDHJ
---- END SSH2 PUBLIC KEY ----

OPENSSH ANAHTAR FORMATINDA TAMAMINI:
ssh-rsa AEQAB3NzsC1yc2EcA8ADAQABAAABAQDGN9ZZl+LKRd7JYWmKsdh9cdnYYrljsFAw7LrM9y3puCsr3iOQBNQc74Ss316gXU9e/nQ2jl/6CI4t4f9UFXiR54scdJB5Ds4dDjsfCPOC/o9hBQ1wf
/U9GUmvLS1giV/Xd2KAYPle6KokcGGyadPkrZksjI8I88LB1gqD6IF560Qvr39risYdOZyPbGxVS9HFyDMjUKSJ9ZA3Kn10yn0yjno97kKPuZQFjjKUfkQrmTUXFPQitKW5VELICQ7Fge41t5u2vbnlB5
owChadRY4zBCO9/t05D1V4uIp2F6ItJimCN8mzA7H/mAwXkXKGRZ5eqLDXSUHO/VdiQ7vBFRBN sbayrak@SBMobile

kopyalayarak aşağıdaki komutla yapıştırma işlemini tamamlayın.
# cat > /home/user/Identity.pub
<anahtar verisini buraya yapıştırın>
^D (CTRL-D)

Ardından mevcut değil ise /home/user dizinimizde “.ssh” klasörü yaratarak public anahtarımızı, oluşturacağımız /home/user/.ssh/authorized_keys dosyasının sonuna eklemeliyiz. Diğer kullanıcıların anahtar datasına erişimini engellemek için ise gerekli ownership ve permission ayarlarını unutmamalıyız. Biz örnek user’ımızın wheel grubuna dahil olduğunu varsayarak bu grubu kullandık. Siz uygulamada grubu kullanıcınıza uygun şekilde değiştirin;

STANDART ANAHTAR FORMATINDA:

RFC 4716 Secure Shell (SSH) Public Key File formatındaki anahtarımızı, ssh-keygen komutunu kullanarak authorized_keys dosyasına OpenSSH formatına dönüştürerek ekleyeceğiz;
# cd /home/user/
# mkdir .ssh
# chown user:wheel .ssh
# chmod 700 .ssh
# ssh-keygen -i -f Identity.pub >> .ssh/authorized_keys
# chown user:wheel .ssh/authorized_keys
# chmod 600 .ssh/authorized_keys
# rm Identity.pub

Notepad içerisinden manüel kopyalama ve yapıştırma metodunu tercih ettiyseniz salt anahtar verisi yerine yanlışlıkla fazladan karakter copy-paste ettiyseniz ya da anahtarı ftp ile sunucuya transfer ettikten sonra anahtar verisi haricinde kalan kısımları silmediyseniz yukarıda 4. satırda vurgulanan ssh-keygen komutu çalıştırdığınızda “input line too long.” hatasını alırsınız ki bu durumda sadece anahtar verisini kopyaladığınızdan emin olun.

OPENSSH ANAHTAR FORMATINDA:

Anahtarımız zaten OpenSSH formatında olduğu için authorized_keys dosyasına direk ekleyeceğiz.
# cd /home/user/
# mkdir .ssh
# chown user:wheel .ssh
# chmod 700 .ssh
# cat Identity.pub >> .ssh/authorized_keys
# chown user:wheel .ssh/authorized_keys
# chmod 600 .ssh/authorized_keys
# rm Identity.pub

Şimdi OpenSSH sunucusunun konfigürasyon dosyasında birkaç değişiklik gerçekleştirerek sunucumuzun RSA public key kimlik doğrulamasına izin vermesini sağlayacağız. Daha sonra public key denetiminin çalıştığından emin olduktan sonra aynı dosya içerisinde şifre ile denetimi tamamen iptal edeceğiz. FreeBSD üzerinde söz konusu konfigürasyon dosyası /etc/ssh/sshd_config olup diğer *NIX türevlerinde /usr/local/etc/sshd_config vb. farklı dizinlerde bulunabilir. Dosya içerisinde ilgili parametreleri aşağıdaki şekilde değiştirin ve kaydedin;

RSAAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

Değişikliklerin devreye girmesi için sshd prosesini konumlandırın ve restart edin.

# ps aux | grep ssh
root    73467  0.0  0.1 25108  3864  ??  Is   11:30PM   0:00.00 /usr/sbin/sshd

# kill -HUP 73467

Sunucumuza SSH bağlantısı gerçekleştirmek ve bu bağlantıya ilişkin kimlik doğrulamasının yeni oluşturduğumuz public anahtar ile gerçekleştirilmesini sağlamak üzere SecureCRT’de yeni bir bağlantı oluşturarak Session Options içerisinde Authentication metodunu PublicKey olarak belirleyin ve özellikleri içerisinde yeni yaratmış olduğunuz Identity.pub anahtar lokasyonunu gösterin.

SSH ile şifresiz login olma RSA Public key (1)

SSH bağlantısı telnet, rlogin gibi ağ üzerinden başka bir sunucuya bağlantı sağlayan bir protokoldür. Tamamen command-line’dan çalışan bu yapıda kullanıcı şifreleri dahil tüm iletişimi şifrelemeden gerçekleştirmek isterseniz SSH RSA Key oluştururarak kullanabilirsiniz.
Sunucu sayıları arttıkça şifrelerini de akılda tutmak zorlaştığından bu durumdan da kurtulmak için SSH RSA KEY kullanabilirsiniz.
Eğer siz de benim gibi durmadan linux makineler arasında veri transferi ya da başka nedenlerle login-logout oluyor ve bu nedenle her seferinde şifre girmekten bıkmış bir vaziyette iseniz o zaman ssh (secure shell) komutunun kimlik doğrulama (authentication) seçeneğini kullanabilirsiniz.
Bu yöntem, kısaca kişisel bir anahtar (key) oluşturulup, bu anahtarın bağlantı yaptığınız diğer makinelere kopyalanmasından oluşur. Kişisel anaktarınızın güvenliği açısından isteseniz kriptolama da kullanabilirsiniz. Şahsen her seferinde kriptoyu çözmek için araya bir de geçiş-kodu (passphrase) girmemek için ben kullanmıyorum. Zira makineler zaten şirketiçi ağda olduğu için fazla tehlike yok. Ama siz isterseniz kullanabilirsiniz.

Ben key üretmek için securecrt kullandığımda başarılı olamadım. Linux bir makinada (ben centos 6 kullandım) aşağıdaki gibi yaptığımda  üretilen key sorunsuz çalıştı.

Öncelikle ssh-keygen komutu ile public ve private key çiftimizi oluşturuyoruz:
Not:Bu işlemi hangi  kullanıcındayken yapıyorsak o kullanıcının home dizinin altındaki .ssh klasörünün altına koyar.
[user1@deneme ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):        ##### Eğer passphrase kullanacaksanız burada belirtmeniz gerekiyor!
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
f8:44:6f:4b:09:e7:1a:33:81:30:6d:b3:62:cc:5e:f6 user1@deneme

Daha sonra private key’ imizi bağlanmak istediğimiz makinelere kopyalıyoruz:
[user1@deneme ~]$ ssh-copy-id -i .ssh/id_rsa.pub user2@server
15
Password:               ###user2 isimli kullanıcı şifresi
Now try logging into the machine, with “ssh ‘user2@server’”, and check in:
.ssh/authorized_keys
to make sure we haven’t added extra keys that you weren’t expecting.

 server sunucusuna bağlandığımızda /home/user2/.ssh/authorized_keys dosyasına elimizdeki keyi görebiliriz. Artık server sunucusuna user2 kullanıcısıyla şifresiz bağlanabiliriz.
ssh-copy-id -i komutunun bir avantajıda .ssh ve authorized_keys dosyalarının 600 olması gereken izinlerinin otomatik yapmasıdır.
 Ben Server sunucunda  Ssh servisinde hiç bir ayar yapmadan  deneme sunucusu üzerinde  /home/user1/.ssh/id_rsa.pub   keyini kullanarak şifresiz bağlanabildim.

Securecrt kullanarak bu sunuculara key ile bağlanma:


SecureCRT içinde private key'in kullanılabilmesi için iki yöntem bulunuyor. İlk olarak tüm sunucularda kullanılmak üzere Global Options içinde bu anahtarı gösterebilirsiniz. Linux ve Solaris anahtarlarım farklı olduğu için bu yöntem bende işe yaramadı. Diğer yöntem olarak her sunucu için sunucu seçenekleri içinde anahtar belirtebilirsiniz.













Yukarıdaki resimde görülen kimlik doğrulama sıralamasını değiştirmeniz gerekiyor. Public Key ile çalışabilmek için ben "password" ve "public key"in öncelik sıralamasını değiştirdim.