Vodem’in (Huawei 4231) Linux’ta Ethernet Olarak Kullanımı

Elime Vodafone’un bir modemi (Vodem) geçti. Bilgisayarıma taktığımda Linux bir ethernet olarak görmedi ve doğrudan çalışmadı. Daha önce Turkcell’in yeni nesil VINN’larında bu hiç başıma gelmediğinden, bir miktar uğraşmam gerekti.

Huawei’nin K4203 isimli bir modeliymiş (lsusb sağolsun). Kendisi öntanımlı olarak MBIM isimli, Linux 3.8’de desteği gelen bir protokolle bağlanıyormuş (Google sağolsun). Bir sonraki nesil bir cihaz kısaca. Ama ethernet aygıtı olarak da çalıştırmak da mümkün. Bunun için usb_modeswitch ile cihaza komut gönderilmesi gerekiyor.

lsusb çıktısında aygıtın ID’sini 12F1:1F1C olarak görüyoruz:

# lsusb
# lsusb | grep Huawei
Bus 002 Device 012: ID 12f1:1f1c Huawei Technologies Co., Ltd.

usb_modeswitch ile şu komutu gönderince kendisi bir ethernet aygıtına dönüşüyor:

# usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000
Taking all parameters from the command line

* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.5 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)

! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor= 0x12d1
DefaultProduct= 0x1f1c
TargetVendor= not set
TargetProduct= not set
TargetClass= not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="55534243123456780000000000000011062000000101000100000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check disabled
System integration mode disabled

Looking for default devices ...
searching devices, found USB ID 12d1:1f1c
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 04f2:b230
Found device in default mode, class or configuration (1)
Accessing device 012 on bus 002 ...
Getting the current device configuration ...
OK, got current device configuration (1)
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Vodafone(Huawei)
Product: HUAWEI Mobile
Serial No.: FFFFFFFFFFFFFFFF
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
-> Run lsusb to note any changes. Bye.

Artık lsusb ile baktığımızda USB ID’sinin de değiştiğini görüyoruz:

# lsusb | grep Huawei
Bus 002 Device 013: ID 12d1:1590 Huawei Technologies Co., Ltd. 

Şimdi bir ağ aygıtı olarak da onu görebilmeliyiz ve eğer ağ yöneticimiz otomatik IP almaya ayarlıysa IP’sini bile almış olmalı:

# ip a
8: enp0s29u1u3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 86:c9:ec:4d:51:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.9.100/24 brd 192.168.9.255 scope global enp0s29u1u3
valid_lft forever preferred_lft forever

Bu yaptığımız ayarlar, ne yazık ki kalıcı değil. Modemin üzerine böyle bir bilgi yazamıyoruz. Onun yerine Linux’un aygıt yöneticisi olan udev’e bu modemin her takıldığını farkettiğinde bu komutu çalıştırmasını söylememiz gerekiyor.

Bunun için udev’in kuralları okuyabileceği bir dosya oluşturuyoruz:

echo 'ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1f1c", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000"'> /etc/udev/rules.d/45-usb_modeswitch.rules

udev’e kuralları tekrar okumasını söylüyoruz:

# udevadm control --reload-rules

Artık “Vodem”i taktığımızda, otomatik olarak ethernet kartı olarak görünmeli ve DHCP’ten IP alabilmeli.

Not: Aygıta gönderilmesi gereken “55534243123456780000000000000011062000000101000100000000000000” gibi bir mesajı kafadan yazmadım :). İnternet’ten araştırdığımda rastladım. Sadece bu cihaz değil, başka Huawei cihazlarında da işe yarıyor gibi okudum. Teknik kaynağını bilen varsa, yorumlara eklerse sevinirim.

9 Mayıs 2016

Posted In: Gezegen

Vodem’in (Huawei 4231) Linux’ta Ethernet Olarak Kullanımı

Elime Vodafone’un bir modemi (Vodem) geçti. Bilgisayarıma taktığımda Linux bir ethernet olarak görmedi ve doğrudan çalışmadı. Daha önce Turkcell’in yeni nesil VINN’larında bu hiç başıma gelmediğinden, bir miktar uğraşmam gerekti.

Huawei’nin K4203 isimli bir modeliymiş (lsusb sağolsun). Kendisi öntanımlı olarak MBIM isimli, Linux 3.8’de desteği gelen bir protokolle bağlanıyormuş (Google sağolsun). Bir sonraki nesil bir cihaz kısaca. Ama ethernet aygıtı olarak da çalıştırmak da mümkün. Bunun için usb_modeswitch ile cihaza komut gönderilmesi gerekiyor.

lsusb çıktısında aygıtın ID’sini 12F1:1F1C olarak görüyoruz:

# lsusb
# lsusb | grep Huawei
Bus 002 Device 012: ID 12f1:1f1c Huawei Technologies Co., Ltd.

usb_modeswitch ile şu komutu gönderince kendisi bir ethernet aygıtına dönüşüyor:

# usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000
Taking all parameters from the command line

* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.5 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)

! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor= 0x12d1
DefaultProduct= 0x1f1c
TargetVendor= not set
TargetProduct= not set
TargetClass= not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="55534243123456780000000000000011062000000101000100000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check disabled
System integration mode disabled

Looking for default devices ...
searching devices, found USB ID 12d1:1f1c
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 04f2:b230
Found device in default mode, class or configuration (1)
Accessing device 012 on bus 002 ...
Getting the current device configuration ...
OK, got current device configuration (1)
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Vodafone(Huawei)
Product: HUAWEI Mobile
Serial No.: FFFFFFFFFFFFFFFF
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
-> Run lsusb to note any changes. Bye.

Artık lsusb ile baktığımızda USB ID’sinin de değiştiğini görüyoruz:

# lsusb | grep Huawei
Bus 002 Device 013: ID 12d1:1590 Huawei Technologies Co., Ltd. 

Şimdi bir ağ aygıtı olarak da onu görebilmeliyiz ve eğer ağ yöneticimiz otomatik IP almaya ayarlıysa IP’sini bile almış olmalı:

# ip a
8: enp0s29u1u3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 86:c9:ec:4d:51:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.9.100/24 brd 192.168.9.255 scope global enp0s29u1u3
valid_lft forever preferred_lft forever

Bu yaptığımız ayarlar, ne yazık ki kalıcı değil. Modemin üzerine böyle bir bilgi yazamıyoruz. Onun yerine Linux’un aygıt yöneticisi olan udev’e bu modemin her takıldığını farkettiğinde bu komutu çalıştırmasını söylememiz gerekiyor.

Bunun için udev’in kuralları okuyabileceği bir dosya oluşturuyoruz:

echo 'ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1f1c", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000"'> /etc/udev/rules.d/45-usb_modeswitch.rules

udev’e kuralları tekrar okumasını söylüyoruz:

# udevadm control --reload-rules

Artık “Vodem”i taktığımızda, otomatik olarak ethernet kartı olarak görünmeli ve DHCP’ten IP alabilmeli.

Not: Aygıta gönderilmesi gereken “55534243123456780000000000000011062000000101000100000000000000” gibi bir mesajı kafadan yazmadım :). İnternet’ten araştırdığımda rastladım. Sadece bu cihaz değil, başka Huawei cihazlarında da işe yarıyor gibi okudum. Teknik kaynağını bilen varsa, yorumlara eklerse sevinirim.

9 Mayıs 2016

Posted In: Gezegen

Vodem’in (Huawei 4231) Linux’ta Ethernet Olarak Kullanımı

Elime Vodafone’un bir modemi (Vodem) geçti. Bilgisayarıma taktığımda Linux bir ethernet olarak görmedi ve doğrudan çalışmadı. Daha önce Turkcell’in yeni nesil VINN’larında bu hiç başıma gelmediğinden, bir miktar uğraşmam gerekti.

Huawei’nin K4203 isimli bir modeliymiş (lsusb sağolsun). Kendisi öntanımlı olarak MBIM isimli, Linux 3.8’de desteği gelen bir protokolle bağlanıyormuş (Google sağolsun). Bir sonraki nesil bir cihaz kısaca. Ama ethernet aygıtı olarak da çalıştırmak da mümkün. Bunun için usb_modeswitch ile cihaza komut gönderilmesi gerekiyor.

lsusb çıktısında aygıtın ID’sini 12F1:1F1C olarak görüyoruz:

# lsusb
# lsusb | grep Huawei
Bus 002 Device 012: ID 12f1:1f1c Huawei Technologies Co., Ltd.

usb_modeswitch ile şu komutu gönderince kendisi bir ethernet aygıtına dönüşüyor:

# usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000
Taking all parameters from the command line

* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.5 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)

! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor= 0x12d1
DefaultProduct= 0x1f1c
TargetVendor= not set
TargetProduct= not set
TargetClass= not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="55534243123456780000000000000011062000000101000100000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check disabled
System integration mode disabled

Looking for default devices ...
searching devices, found USB ID 12d1:1f1c
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 04f2:b230
Found device in default mode, class or configuration (1)
Accessing device 012 on bus 002 ...
Getting the current device configuration ...
OK, got current device configuration (1)
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Vodafone(Huawei)
Product: HUAWEI Mobile
Serial No.: FFFFFFFFFFFFFFFF
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
-> Run lsusb to note any changes. Bye.

Artık lsusb ile baktığımızda USB ID’sinin de değiştiğini görüyoruz:

# lsusb | grep Huawei
Bus 002 Device 013: ID 12d1:1590 Huawei Technologies Co., Ltd. 

Şimdi bir ağ aygıtı olarak da onu görebilmeliyiz ve eğer ağ yöneticimiz otomatik IP almaya ayarlıysa IP’sini bile almış olmalı:

# ip a
8: enp0s29u1u3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 86:c9:ec:4d:51:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.9.100/24 brd 192.168.9.255 scope global enp0s29u1u3
valid_lft forever preferred_lft forever

Bu yaptığımız ayarlar, ne yazık ki kalıcı değil. Modemin üzerine böyle bir bilgi yazamıyoruz. Onun yerine Linux’un aygıt yöneticisi olan udev’e bu modemin her takıldığını farkettiğinde bu komutu çalıştırmasını söylememiz gerekiyor.

Bunun için udev’in kuralları okuyabileceği bir dosya oluşturuyoruz:

echo 'ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1f1c", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1f1c -W -I -M 55534243123456780000000000000011062000000101000100000000000000"'> /etc/udev/rules.d/45-usb_modeswitch.rules

udev’e kuralları tekrar okumasını söylüyoruz:

# udevadm control --reload-rules

Artık “Vodem”i taktığımızda, otomatik olarak ethernet kartı olarak görünmeli ve DHCP’ten IP alabilmeli.

Not: Aygıta gönderilmesi gereken “55534243123456780000000000000011062000000101000100000000000000” gibi bir mesajı kafadan yazmadım :). İnternet’ten araştırdığımda rastladım. Sadece bu cihaz değil, başka Huawei cihazlarında da işe yarıyor gibi okudum. Teknik kaynağını bilen varsa, yorumlara eklerse sevinirim.

9 Mayıs 2016

Posted In: Gezegen

Linux’ta saat ileri/geri alınma zamanlarının kontrolü

Bilgi teknolojilerinden anlamayan yöneticiler sağolsun, 2011’de olduğu gibi bu yıl da, son dakikada Türkiye’nin “daylight saving time” (dst) uygulamasının tarihleri çok kısa bir zaman kala değişti.

Bu da, çalışan on yüz milyon sunucunun bu kısa süre içerisinde tarihler değişecek biçimde tek tek değiştirilmesi demek. Canlı sunucular için otomatik güncellemenin tercih edilmeyebileceği ya da her sunucunun İnternet bağlantısının olmayabileceği düşünülürse; bu çok ciddi bir iş yükü demek. Bankalar, havayolları gibi saatlerin çok kritik olduğu sistemlerdeki olası problemleri saymıyorum bile. Anadolujet’te yakın zamanda böyle bir sorun yaşadım örneğin:

anadolujet_saat_farki

Bilet almaya çalışırken, bir ekranda 10:00 uçağını seçerken, diğer bir kutuda 11:00 uçağını seçmiş gibi görünüyorum yukarıda.

Normalde saatlerin değişmesi gereken 25 Ekim 04:00 tarihine 1.5 günden az zaman kala, “acaba sunucum saatini doğru zamanda geri alacak mı?” diye bir soru işareti varsa kafanızda bunu Linux’ta kontrol etmek çok kolay.

zdump -v Europe/Istanbul |grep 2015

komutunun çıktısı size yanıtı verecektir. Eğer şuna benzer bir çıktı alıyorsanız, zaman bilgisini güncellemeniz gerekiyor demektir:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 00:59:59 2015 UTC = Sun Oct 25 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 01:00:00 2015 UTC = Sun Oct 25 03:00:00 2015 EET isdst=0 gmtoff=7200

Linux’ta bu bilgiyi tutan tzdata ve tzdata-java paketinin dağıtımınızdaki güncellemesini bulup yapmalısınız.

Güncelleme yapılmışsa, çıktınız şuna benzer olmalı:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 00:59:59 2015 UTC = Sun Nov  8 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 01:00:00 2015 UTC = Sun Nov  8 03:00:00 2015 EET isdst=0 gmtoff=7200

23 Ekim 2015

Posted In: Gezegen

Linux’ta saat ileri/geri alınma zamanlarının kontrolü

Bilgi teknolojilerinden anlamayan yöneticiler sağolsun, 2011’de olduğu gibi bu yıl da, son dakikada Türkiye’nin “daylight saving time” (dst) uygulamasının tarihleri çok kısa bir zaman kala değişti.

Bu da, çalışan on yüz milyon sunucunun bu kısa süre içerisinde tarihler değişecek biçimde tek tek değiştirilmesi demek. Canlı sunucular için otomatik güncellemenin tercih edilmeyebileceği ya da her sunucunun İnternet bağlantısının olmayabileceği düşünülürse; bu çok ciddi bir iş yükü demek. Bankalar, havayolları gibi saatlerin çok kritik olduğu sistemlerdeki olası problemleri saymıyorum bile. Anadolujet’te yakın zamanda böyle bir sorun yaşadım örneğin:

anadolujet_saat_farki

Bilet almaya çalışırken, bir ekranda 10:00 uçağını seçerken, diğer bir kutuda 11:00 uçağını seçmiş gibi görünüyorum yukarıda.

Normalde saatlerin değişmesi gereken 25 Ekim 04:00 tarihine 1.5 günden az zaman kala, “acaba sunucum saatini doğru zamanda geri alacak mı?” diye bir soru işareti varsa kafanızda bunu Linux’ta kontrol etmek çok kolay.

zdump -v Europe/Istanbul |grep 2015

komutunun çıktısı size yanıtı verecektir. Eğer şuna benzer bir çıktı alıyorsanız, zaman bilgisini güncellemeniz gerekiyor demektir:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 00:59:59 2015 UTC = Sun Oct 25 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 01:00:00 2015 UTC = Sun Oct 25 03:00:00 2015 EET isdst=0 gmtoff=7200

Linux’ta bu bilgiyi tutan tzdata ve tzdata-java paketinin dağıtımınızdaki güncellemesini bulup yapmalısınız.

Güncelleme yapılmışsa, çıktınız şuna benzer olmalı:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 00:59:59 2015 UTC = Sun Nov  8 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 01:00:00 2015 UTC = Sun Nov  8 03:00:00 2015 EET isdst=0 gmtoff=7200

23 Ekim 2015

Posted In: Gezegen

Linux’ta saat ileri/geri alınma zamanlarının kontrolü

Bilgi teknolojilerinden anlamayan yöneticiler sağolsun, 2011’de olduğu gibi bu yıl da, son dakikada Türkiye’nin “daylight saving time” (dst) uygulamasının tarihleri çok kısa bir zaman kala değişti.

Bu da, çalışan on yüz milyon sunucunun bu kısa süre içerisinde tarihler değişecek biçimde tek tek değiştirilmesi demek. Canlı sunucular için otomatik güncellemenin tercih edilmeyebileceği ya da her sunucunun İnternet bağlantısının olmayabileceği düşünülürse; bu çok ciddi bir iş yükü demek. Bankalar, havayolları gibi saatlerin çok kritik olduğu sistemlerdeki olası problemleri saymıyorum bile. Anadolujet’te yakın zamanda böyle bir sorun yaşadım örneğin:

anadolujet_saat_farki

Bilet almaya çalışırken, bir ekranda 10:00 uçağını seçerken, diğer bir kutuda 11:00 uçağını seçmiş gibi görünüyorum yukarıda.

Normalde saatlerin değişmesi gereken 25 Ekim 04:00 tarihine 1.5 günden az zaman kala, “acaba sunucum saatini doğru zamanda geri alacak mı?” diye bir soru işareti varsa kafanızda bunu Linux’ta kontrol etmek çok kolay.

zdump -v Europe/Istanbul |grep 2015

komutunun çıktısı size yanıtı verecektir. Eğer şuna benzer bir çıktı alıyorsanız, zaman bilgisini güncellemeniz gerekiyor demektir:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 00:59:59 2015 UTC = Sun Oct 25 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Oct 25 01:00:00 2015 UTC = Sun Oct 25 03:00:00 2015 EET isdst=0 gmtoff=7200

Linux’ta bu bilgiyi tutan tzdata ve tzdata-java paketinin dağıtımınızdaki güncellemesini bulup yapmalısınız.

Güncelleme yapılmışsa, çıktınız şuna benzer olmalı:

[root@barbun ~]# zdump -v Europe/Istanbul |grep 2015
Europe/Istanbul  Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 02:59:59 2015 EET isdst=0 gmtoff=7200
Europe/Istanbul  Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 04:00:00 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 00:59:59 2015 UTC = Sun Nov  8 03:59:59 2015 EEST isdst=1 gmtoff=10800
Europe/Istanbul  Sun Nov  8 01:00:00 2015 UTC = Sun Nov  8 03:00:00 2015 EET isdst=0 gmtoff=7200

23 Ekim 2015

Posted In: Gezegen

Telnet ile SMTP doğrulama ile e-posta gönderiminin test edilmesi

Herhangi bir sunucudan e-posta gönderip gönderemediğinin en temel yöntemi, telnet komutuyla herhangi bir e-posta istemcisinin haberleşmesini taklit etmek. Böylece sorunun (varsa) nerede olduğunu tespit etmek mümkün. Eğer telnet’le e-posta gönderirken sorun yaşamıyorsanız, sorun kullanmak istediğiniz istemci ayarlarında demektir.

İstemciler her zaman anlamlandırabileceğimiz hata mesajları da vermeyebiliyor, telnet ile gönderim, bir sorun varsa hangi noktada olduğunu tespit etmekte de yararlı olabilir.

Eğer karşı sunucuya relay hakkınız varsa, isim/parola girmeden kolaylıkla e-posta gönderebilirsiniz. Aşağıdaki anlatımda “AUTH LOGIN” ile “235 2.7.0 Authentication successful” satırları arasında kalan kısmı toptan pas geçebilirsiniz.

Eğer çoğu durumda olduğu gibi e-posta gönderimi için isim/parola doğrulaması yapmanız gerekiyorsa, bu bilgileri base64 kodlayarak göndermeniz gerekiyor. Bunu aşağıdaki perl satırı ile bu kodlamayı yapabiliriz:

perl -MMIME::Base64 -e 'print encode_base64("icerik");'

Örneğin,

[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("gonderen@alanadi.com");'
Z29uZGVyZW4uY29t
[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("parolacim");'
cGFyb2xhY2lt

Şimdi e-posta gönderimini test edebiliriz:

[dfisek@karadut ~]$ telnet eposta.alanadi.com 25
Trying 195.112.152.4...
Connected to 195.112.152.4.
Escape character is '^]'.
220 eposta.alanadi.com ESMTP Postfix
AUTH LOGIN
334 VXNlcm5hbWU6

Burada belirtilen VXNlcm5hbWU6 ifadesi, size base64 kodlanmış olarak kullanıcı adınızı girmenizi istiyor. Girelim biz de (üstte kodladığımız ifadeyle):

Z29uZGVyZW4uY29t
334 UGFzc3dvcmQ6

Bu kez de bize base64 kodlanmış olarak parolamızı sordu. Girelim yine (üstte kodladığımız ifadeyle):

cGFyb2xhY2lt
235 2.7.0 Authentication successful

Parola doğrulama işlemini bitirdik. Artık e-postamızla ilgili sunucuya bilgi verebiliriz:

MAIL FROM: gonderen@alanadi.com
250 2.1.0 Ok
RCPT TO: alici@alanadi.com
250 2.1.0 Ok
DATA
354 End data with .

Bu başlıklar, e-postanın kimden kime gideceğini e-posta sunucusuna söyledi. Biz de e-postanın içeriğini yazmak istediğimizi DATA komutuyla e-posta sunucusuna söyledik.

Önce e-postanın başlıklarını yazıyoruz (küçüktür-büyüktür işaretlerinden önce/sonra gelen boşlukları siliniz):

From: Gonderen Adi < gonderen@alanadi.com >
To: Alici Adi < alici@alanadi.com >
Subject: E-posta gönderim testi

İlk “MAIL FROM” e-posta sunucusuna bilgi verirken, burada kullandığımız ikinci “FROM:” göndermek istediğiniz postanın içinde yer alıyor. Artık e-postanın gövdesini yazabiliriz. Yazdıklarımız bittiğinde bir kez boş satıra enter’a, daha sonra bir kez . yazıp enter’a, son olarak da tekrar boş satıra enter’a basmamız gerekiyor. Böylece e-postanın bittiği anlaşılıyor:

E-postam geldiyse beni iki kere pingle.

.
250 2.0.0 Ok: queued as 384E125B587

E-postamız başarıyla kuyruğa alındı.

Bu aşamalardan herhangi birinde takılıyorsanız, gönderimde tam sorunun nerede olduğunu buldunuz demektir.

8 Haziran 2014

Posted In: Gezegen

Telnet ile SMTP doğrulama ile e-posta gönderiminin test edilmesi

Herhangi bir sunucudan e-posta gönderip gönderemediğinin en temel yöntemi, telnet komutuyla herhangi bir e-posta istemcisinin haberleşmesini taklit etmek. Böylece sorunun (varsa) nerede olduğunu tespit etmek mümkün. Eğer telnet’le e-posta gönderirken sorun yaşamıyorsanız, sorun kullanmak istediğiniz istemci ayarlarında demektir.

İstemciler her zaman anlamlandırabileceğimiz hata mesajları da vermeyebiliyor, telnet ile gönderim, bir sorun varsa hangi noktada olduğunu tespit etmekte de yararlı olabilir.

Eğer karşı sunucuya relay hakkınız varsa, isim/parola girmeden kolaylıkla e-posta gönderebilirsiniz. Aşağıdaki anlatımda “AUTH LOGIN” ile “235 2.7.0 Authentication successful” satırları arasında kalan kısmı toptan pas geçebilirsiniz.

Eğer çoğu durumda olduğu gibi e-posta gönderimi için isim/parola doğrulaması yapmanız gerekiyorsa, bu bilgileri base64 kodlayarak göndermeniz gerekiyor. Bunu aşağıdaki perl satırı ile bu kodlamayı yapabiliriz:

perl -MMIME::Base64 -e 'print encode_base64("icerik");'

Örneğin,

[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("gonderen@alanadi.com");'
Z29uZGVyZW4uY29t
[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("parolacim");'
cGFyb2xhY2lt

Şimdi e-posta gönderimini test edebiliriz:

[dfisek@karadut ~]$ telnet eposta.alanadi.com 25
Trying 195.112.152.4...
Connected to 195.112.152.4.
Escape character is '^]'.
220 eposta.alanadi.com ESMTP Postfix
AUTH LOGIN
334 VXNlcm5hbWU6

Burada belirtilen VXNlcm5hbWU6 ifadesi, size base64 kodlanmış olarak kullanıcı adınızı girmenizi istiyor. Girelim biz de (üstte kodladığımız ifadeyle):

Z29uZGVyZW4uY29t
334 UGFzc3dvcmQ6

Bu kez de bize base64 kodlanmış olarak parolamızı sordu. Girelim yine (üstte kodladığımız ifadeyle):

cGFyb2xhY2lt
235 2.7.0 Authentication successful

Parola doğrulama işlemini bitirdik. Artık e-postamızla ilgili sunucuya bilgi verebiliriz:

MAIL FROM: gonderen@alanadi.com
250 2.1.0 Ok
RCPT TO: alici@alanadi.com
250 2.1.0 Ok
DATA
354 End data with .

Bu başlıklar, e-postanın kimden kime gideceğini e-posta sunucusuna söyledi. Biz de e-postanın içeriğini yazmak istediğimizi DATA komutuyla e-posta sunucusuna söyledik.

Önce e-postanın başlıklarını yazıyoruz (küçüktür-büyüktür işaretlerinden önce/sonra gelen boşlukları siliniz):

From: Gonderen Adi < gonderen@alanadi.com >
To: Alici Adi < alici@alanadi.com >
Subject: E-posta gönderim testi

İlk “MAIL FROM” e-posta sunucusuna bilgi verirken, burada kullandığımız ikinci “FROM:” göndermek istediğiniz postanın içinde yer alıyor. Artık e-postanın gövdesini yazabiliriz. Yazdıklarımız bittiğinde bir kez boş satıra enter’a, daha sonra bir kez . yazıp enter’a, son olarak da tekrar boş satıra enter’a basmamız gerekiyor. Böylece e-postanın bittiği anlaşılıyor:

E-postam geldiyse beni iki kere pingle.

.
250 2.0.0 Ok: queued as 384E125B587

E-postamız başarıyla kuyruğa alındı.

Bu aşamalardan herhangi birinde takılıyorsanız, gönderimde tam sorunun nerede olduğunu buldunuz demektir.

8 Haziran 2014

Posted In: Gezegen

Telnet ile SMTP doğrulama ile e-posta gönderiminin test edilmesi

Herhangi bir sunucudan e-posta gönderip gönderemediğinin en temel yöntemi, telnet komutuyla herhangi bir e-posta istemcisinin haberleşmesini taklit etmek. Böylece sorunun (varsa) nerede olduğunu tespit etmek mümkün. Eğer telnet’le e-posta gönderirken sorun yaşamıyorsanız, sorun kullanmak istediğiniz istemci ayarlarında demektir.

İstemciler her zaman anlamlandırabileceğimiz hata mesajları da vermeyebiliyor, telnet ile gönderim, bir sorun varsa hangi noktada olduğunu tespit etmekte de yararlı olabilir.

Eğer karşı sunucuya relay hakkınız varsa, isim/parola girmeden kolaylıkla e-posta gönderebilirsiniz. Aşağıdaki anlatımda “AUTH LOGIN” ile “235 2.7.0 Authentication successful” satırları arasında kalan kısmı toptan pas geçebilirsiniz.

Eğer çoğu durumda olduğu gibi e-posta gönderimi için isim/parola doğrulaması yapmanız gerekiyorsa, bu bilgileri base64 kodlayarak göndermeniz gerekiyor. Bunu aşağıdaki perl satırı ile bu kodlamayı yapabiliriz:

perl -MMIME::Base64 -e 'print encode_base64("icerik");'

Örneğin,

[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("gonderen@alanadi.com");'
Z29uZGVyZW4uY29t
[dfisek@karadut ~]$ perl -MMIME::Base64 -e 'print encode_base64("parolacim");'
cGFyb2xhY2lt

Şimdi e-posta gönderimini test edebiliriz:

[dfisek@karadut ~]$ telnet eposta.alanadi.com 25
Trying 195.112.152.4...
Connected to 195.112.152.4.
Escape character is '^]'.
220 eposta.alanadi.com ESMTP Postfix
AUTH LOGIN
334 VXNlcm5hbWU6

Burada belirtilen VXNlcm5hbWU6 ifadesi, size base64 kodlanmış olarak kullanıcı adınızı girmenizi istiyor. Girelim biz de (üstte kodladığımız ifadeyle):

Z29uZGVyZW4uY29t
334 UGFzc3dvcmQ6

Bu kez de bize base64 kodlanmış olarak parolamızı sordu. Girelim yine (üstte kodladığımız ifadeyle):

cGFyb2xhY2lt
235 2.7.0 Authentication successful

Parola doğrulama işlemini bitirdik. Artık e-postamızla ilgili sunucuya bilgi verebiliriz:

MAIL FROM: gonderen@alanadi.com
250 2.1.0 Ok
RCPT TO: alici@alanadi.com
250 2.1.0 Ok
DATA
354 End data with .

Bu başlıklar, e-postanın kimden kime gideceğini e-posta sunucusuna söyledi. Biz de e-postanın içeriğini yazmak istediğimizi DATA komutuyla e-posta sunucusuna söyledik.

Önce e-postanın başlıklarını yazıyoruz (küçüktür-büyüktür işaretlerinden önce/sonra gelen boşlukları siliniz):

From: Gonderen Adi < gonderen@alanadi.com >
To: Alici Adi < alici@alanadi.com >
Subject: E-posta gönderim testi

İlk “MAIL FROM” e-posta sunucusuna bilgi verirken, burada kullandığımız ikinci “FROM:” göndermek istediğiniz postanın içinde yer alıyor. Artık e-postanın gövdesini yazabiliriz. Yazdıklarımız bittiğinde bir kez boş satıra enter’a, daha sonra bir kez . yazıp enter’a, son olarak da tekrar boş satıra enter’a basmamız gerekiyor. Böylece e-postanın bittiği anlaşılıyor:

E-postam geldiyse beni iki kere pingle.

.
250 2.0.0 Ok: queued as 384E125B587

E-postamız başarıyla kuyruğa alındı.

Bu aşamalardan herhangi birinde takılıyorsanız, gönderimde tam sorunun nerede olduğunu buldunuz demektir.

8 Haziran 2014

Posted In: Gezegen

Sunucu Saatlerinin Doğruluğu ve NTP

Sunucular 7×24 çalışan ve sürekli hizmet veren bilgisayarlar. Hiç kapanmayan bilgisayarların da saatlerinin bir kez düzgün ayarlandıktan sonra hiç bozulmamasını bekleyebilirsiniz.

Ama yanılırsınız :).

Sunucuların saatleri milisaniyeler düzeyinden başlayarak kayabilirler, hatta bu kayma zaman içerisinde dakikaları bile bulabilir. Artık bir donanımda tek sunucu da çalıştırmıyoruz, sanal sunucularda bu kayma miktarı daha da fazla artıyor (donanımın saati paylaşıldığı için).

Ne Önemi Var?

Eeee… bir sunucunun saati birkaç dakika ileride ya da geride olsa ne farkeder diyebilirsiniz. Sorun şu ki, sunucularda yapılan işlemlerin çoğunluğu saniye (hatta milisaniye) biriminde sürelerde gerçekleşiyor.

Birçok sunucuyu ilgilendiren bir işlem yaptığınızı farzedelim, aynı anda birinin saati 16:54:22, ötekinin saati 16:54:17, bir başkasınınkinin 16:55:22 olsun. O işlemin tam olarak hangi sunucuda hangi saatte yapıldığını nereden bileceksiniz? İşlemin yapılmasının ne kadar sürdüğünü ve akışını göremeyeceksiniz.

Sistemde gezinen birini takip ettiğinizi düşünelim, hangi sunucudan sunucuya atladığını, tam ne işlem yaptığını, vs çözmeye çalışırken aradaki zaman farkları kafanızı iyice karıştıracaktır.

Keza aynısı sistem kayıtlarını inceleyerek, geçmişe dönük inceleme yapmanız gereken herhangi bir çalışmada geçerli olacaktır.

NTP ile Saatlerimizi Ayarlayalım

Sunucuların zamanlarını ayarlamak için bir “kuzey yıldızı”na gereksinim duyacaklarını, yıllaar yıllar önce düşünmüş başkaları da. NTP (Network Time Protocol = Ağ Zaman Protokolü) adı verilen bir İnternet standardı ve sunucular arasında haberleşme yöntemi ortaya koymuşlar.

Tek işi zaman servisi vermek (yani saatin kaç olduğunu söylemek) olan NTP sunucularına bağlanan diğer sunucu bilgisayarları, saatin tam olarak kaç olduğunu öğrenip kendilerini ona göre gerekiyorsa düzeltme yöntemine gidiyorlar.

ntp.org isimli bir alan adı var, pool.ntp.org adresine bağlanan sunucular, “havuz”dan kendileri için en uygun/yakın zaman sunucusunu bularak oradan zaman bilgisini alıyorlar.

ntpdate ile Zamanda Atlamak

Normalde bir saati ayarlamak için, doğrudan saati değiştirir ve o zamana “atlama” yaparız. Saat bir an 16:54:22 iken birden 16:54:17 olabilir örneğin. Linux’ta date komutu aynen bunu yapıyor. ntpdate komutu da bu zamanı NTP sunucusundan çekerek yapan uzak akrabası.

Ancak sunucu kayıtları ve uygulamalarında tutarlılık yine önplanda olduğu noktada bunun sağlıklı olamayacağı birkaç senaryo düşününce ortaya çıkıyor. Zamanı geri aldığınızı farzedelim: 16:54:22 iken saat, zamanı ayarladınız ve (sunucu açısından zamanda geriye gidip) saati 16:54:17 yaptınız. Bu durumda sunucu 16:54:17’yi ve sonraki 5 saliseyi ikinci bir kere daha yaşayacak demektir. Sunucu kayıtlarında önce 16:54:18’de yapılmış bir işlem, sonra 16:54:22’de yapılmış bir işlem, sonra tekrar 16:54:18’de yapılmış ikinci bir işlem kaydedilebilecek demektir.

Aynı zaman damgalı ama aslında farklı iki zamana ait işlem tutarsızlık yaratacaktır. Ayrıca zamanın tekil/biricik/unique olduğu ve doğrusal ilerlediğine güvenerek çeşitli işlemler yapan sunucu servislerinin de güvendiği dağlara kar yağacaktır. Zaman ayarlarken servisleri durdurup, zamanı ayarlayıp, servisi başlatmak da bir çözüm ama çoğu zaman sunucu servisler için o kadarlık bir zaman kaybı da uygun olmuyor.

Üstelik ntpdate kullanılarak yapılabilecek olan, sadece belirli aralıklarla (cron’dan) ntpdate komutunu çalıştırmak.

ntpd ile Zamanın Akışını Değiştirmek

İşte o noktada NTPd adı verilen bir nadide uygulama devreye giriyor. Sunucunuzda sürekli çalışan bir uygulama olan ntpd, sadece anlık olarak değil, sürekli zamanı kontrolü altına alıyor. Belirli aralıklarla gidip uzaktaki NTP sunucusuna bakıp doğru zamanı alıyor.

Kendi yerelindeki zaman ile NTP’den gelen zaman farklı olduğunda ise zamanı doğrudan değiştirmek yerine, sunucudaki zamanı yavaşlatıyor ya da hızlandırıyor.

Örneğin gerçek saatin 16:54:22, sunucu saatimizin 16:57:22 olduğunu düşünelim. ntpd zamanın akışını yavaşlatıyor, bir dakika sürmesi gereken 60 saniyenin yavaaş yavaaaş 65 saniyede ilerlediğini görebiliyorsunuz. Daha uzun süren saniyeler sonucunda, her dakika 5 saniye daha gerçeğe yaklaşıyoruz ve 12 dakika sonunda saatler birbirine eş hale geliyor ve ntpd zamanı normal akışına çeviriyor.

Ya da zamanda geride olduğumuzu farzedelim. Gerçek saat yine 16:54:22 olsun ama bizim yerel saatimiz 16:53:22. Bu kez, zamanı hızlandırıyor. Bizim saatimizle saniyeler hızla akmaya başlıyor ve zaman içinde saatler eşitlendiğinde artık zaman akışı normale dönüyor.

Bilimkurgu filmlerinde gördüğümüz, evrende zamanın belli bir yerde daha hızlı/yavaş akması hayaldi gerçek oldu :).

Bu yöntem sayesinde, sunucu sistemimiz açısından zaman hiçbir zaman tekrar etmezken, zamanda hiç atlama da gerçekleşmiyor. Tüm saniyeler mutlaka yaşanıyor, hiçbir saniye iki kere yaşanmıyor.

ntpd aynı zamanda zaman değişimleri ile ilgili istatistik tutuyor ve sunucunun saati belirli bir zamanda ortalama ne kadar kayıyor bilgisine sahip oluyor. Daha sonra uzaktaki NTP sunucusu ile bağlantısı herhangi bir nedenle belirli bir süre koparsa, elindeki istatistiklere göre tahmin yürüterek zamanı ayarlamaya devam ediyor: “En son 2 gün önce doğru saati almıştım, 2 gündür haber yok. Elimdeki istatistiklere göre, bu sunucunun saati 2 gün içinde ortalama 5 ms kayıyor, o zaman ben de saati ona göre düzenleyeyim” diyerek çalışmasını sürdürüyor.

ntpd / ntpdate Seçimi

Peki ne zaman ntpd, ne zaman ntpdate kullanacağız?

Bir kereliğine zamanı ayarlayıp (aradaki fark günler düzeyinde örneğin), daha sonra tüm servisleri tekrar başlatıp logları da temizleyeceksek ntpdate kullanımı istediğimiz sonuca hızlıca varmamızı sağlıyor. Sonrasında ntpd ile ince kaymaları tutabiliriz.

Çalışan canlı bir sunucu sisteminde ise, bu işlemi ntpd’ye bırakmak ve zamanın daha nazikçe düzenlenmesini sağlamak gerekiyor.

Alternatif olarak görülen cron’dan sık sık ntpdate çalıştırarak sunucudaki saat kaymasını önlemeye çalışmak ise yazının başından beri belirttiğim nedenlerle pek önerilmeyen bir yöntem. Sürekli bir zaman için ntpd var zaten.

ntpdate, yine servislerin önemsenmediği, sık kapatılıp-açılan bir masaüstü sisteminde rahatlıkla tercih edilebilir.

1 Ekim 2013

Posted In: Gezegen

Twitter Auto Publish Powered By : XYZScripts.com