Qmail MTA ile eposta gönderiyorsanız.
Göndermiş olduğunuz e-postaların dkim ile imzalanmış olması gerekmektedir.
Bu işlem için bu adresteki işlemleri yapmanız ve ubuntu için gerekli olan dkim imzasını uygulayacak olan libmail-dkim-perl paketini kurmanız yeterlidir.
Kaynak adres: http://www.qmailtoaster.net/dkim.html
Bu yazıda sizlere bazı linux maiknaların sistem boot işlemi sırasında çıkardığı problemleri
gidermek amaçlı kullandığımız parametreleri anlatmaya çalışacağım.
Uyguladığımız çözümler bazan geçici çözümler olsada
bazende bu problemler bios göncellemesi ile giderilebilmekterdir.
Bir dostumun kullandığı laptop pc de sorun çıkaran türden.
ilk geçici çözüm açılış sırasında grub 'a boot parametresi eklemektir.
sistem boot menüsünü gösterdiğinde grub açılış parametresine ek yapmak için
resimde görüldüğü gibi açılacak sistemi seçip "e" tuşuna basarak edit menüsüne gelelim.
Klavyedeki yön tuşlarını kullanarak aşağıya doğru inelim.
bu ekranda bulmamız gereken sistemin linux kernelini yüklediği kısımdır.
linux /boot/vmlinuz-5.4.0-52-generic satırının en sonuna kadar yine yön tuşları ile gidip.
bir boşluk bıraktıktan sonra gerekli parametreyi eklemektir.
Örnekte nolapic parametresini kullandım.
Gerekli parametreyi ekledikten sonra sistemin yüklenebilmesi için Ctrl+x veya F10 tuşlarını kullanmalıyız.
Eğer grub2 ekranında yaptığımız değişiklikten vazgeçmek istersek Ctrl+c veya F2 tuşlarını kullanabiliriz.
Grub2 Ekranının alt satırlarında bu seçenekler belirtilmiş haldedir.
Linux sistemimiz açıldıktan sonra.
Eklediğimiz parametreyi kalıcı hale getirelim.
Terminali/Uçbirim açın.
sudo su yada Sadece su komutu ile root olun.
nano /etc/default/grub
komutu ile grub parametre dosyasını açın
bu satırı bulup.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Dikkatlice bu hale geririp kaydedin.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nolapic"
nano da ctrl+x kısayolunu kullanın sorulan soruya evet yanıtı verin.
son olarak yine terminalde root olarak
update-grub
komutu verin.
Grub parametresini kalıcı hale getirdik.
Faydalı olması dileğiyle.
Manjaro Linux geliştiricisi olan ve wiki üzerinde de çalışmakta olan Oguzkagan tarafından Türkçe’ye kazandırılan Manjaro Linux Kullanıcı Rehberi, Manjaro Linux tarafından kullanıma sunulmuş bulunuyor. Manjaro Linux Kullanıcı Rehberi içeriğinde, Manjaro Linux kurulumundan, Pacman’e, yazılım yükleme yöntemlerine, GRUB güncellemeye, sistem içi hareket noktalarına kadar her türlü ayrıntıyı bulmak mümkündür. Bunun dışında çeşitli konularda bilgi edinmek üzere Manjaro Linux Wiki’ye buradan, Çeşitli konularda yardım almak üzere Manjaro Linux foruma ise buradan ulaşmak mümkündür.
Manjaro Linux Kullanıcı Rehberi Türkçe edinmek için buradan yararlanabilirsiniz.
Manjaro Linux Kullanıcı Rehberi Türkçe
The backup MX host must accept and queue mails, if the primary mailhost is down for a certain domain. To have a high degree of availability the backup MX host must be located outside the backed up domain. You can setup the backup MX host as a primary or secondary mx for a remote site.
The primary mailhost is down ...
Email is delivered to the backup MX host and queued there ....
Setup of a primary mx host for a remote site
IN MX 10 mail1.backup1.com.
IN MX 20 mail2.backup2.com.
All email for the remote site is delivered to the primary mx host: mail1.backup1.com.
Postfix Configuration on backup1.com:
/etc/postfix/main.cf:
relay_domains = $mydestination the.backed-up.domain.name
smtpd_recipient_restrictions = permit_mynetworks
check_relay_domains
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
the.backed-up.domain.name smtp:[their.mail.host.name]
Setup of a secondary mx host for a remote site
/etc/postfix/main.cf:
relay_domains = $mydestination the.backed-up.domain.name
smtpd_recipient_restrictions = permit_mynetworks
check_relay_domains
sudo nano /boot/grub/custom.cfg
menuentry "ubuntu 20.04 64 bit ISO boot - 64 bit" {
set root=(hd1,msdos1)
set soubor=/home/caylak/ubuntu-20.04-desktop-amd64.iso
loopback loop $soubor
root=(loop)
linux /casper/vmlinuz boot=casper default iso-scan/filename=$soubor quiet splash --- debian-installer/language=tr keyboard-configuration/layoutcode?=tr
initrd /casper/initrd
}
sudo apt-get install bind9 bind9utils dnsutils
sudo nano /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
zone "yourdomain.com" {type master; file "/home/admin/conf/dns/yourdomain.com.db";};
sudo nano /etc/bind/named.conf.options
allow-transfer { 1.2.3.4; };
notify yes;
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
//listen-v6 { any; };
allow-transfer { 1.2.3.4; };
notify yes;
};
sudo nano /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "yourdomain.com" {
type slave;
masters { 4.3.2.1; };
file "/var/lib/bind/yourdomain.com.db";
};
sudo nano /etc/bind/named.conf.options
allow-notify {1.2.3.4;};
sudo service bind9 restart
sudo service bind9 restart
nano /var/lib/bind/yourdomain.com.db
#!/bin/bashFaydalı olması dileğiyle. ..
# caylakpenguen
# Paz 24 May 2020 17:18:38 +03
# Disk Doluluk Kontrolu....
# Disk dolulugu belirli seviyeyi gectiginde
# ilgili kisiye bildirim gonderir.
#cron gorevi icin girdi. 15 dakikada bir calisir.
# */15 * * * * /opt/disk.sh
#Tarih
TARIH=$(date '+%F-%H-%M')
## Sistem Kok Bolumu
DISKADI="/dev/sda1"
## Kime Eposta Gonderilecek...
KIME="admin@local.lan"
#data dosyasi...
MAILFILE="/tmp/eposta.txt"
DISKUSE="/tmp/diskdf.txt"
# % de olarak hesaplanir.
SINIR="90"
kontrol(){
df -h | grep "$DISKADI" | awk '{ print $5}' > $DISKUSE
DURUM=$(cat $DISKUSE | cut -f1 -d%)
if [ $DURUM -ge $SINIR ]; then
echo "UYARI! Disk Kullanimi % $SINIR" > $MAILFILE
echo "" >> $MAILFILE
echo "Sistem Disk doluluk orani. % $DURUM " >> $MAILFILE
echo "Sistem Diskinizi kontrol ediniz." >> $MAILFILE
echo "" >> $MAILFILE
echo "iyi calismalar..." >> $MAILFILE
echo "$(hostname)" >> $MAILFILE
echo "Tarih: $TARIH ." >> $MAILFILE
mail -s "UYARI! Disk Kullanimi 90%" $KIME < $MAILFILE
rm -f $MAILFILE $DISKUSE
fi
}
#
kontrol
~# ssh-keygen
Host github
HostName github.com
User git
IdentityFile ~/.ssh/github/id_rsa
~# git clone https://github.com/geekdinazor/not.py
~# git clone git:geekdinazor/not.py
SSH ve HTTPS bir çok yönden benzeyen protokoller. Daha önce HTTPS hakkında yazdığım için benzer şeyleri tekrar etmek yerine SSH'ın temel bir farkından bahsetmek istiyorum.
Bir SSH bağlantısı için istemci ve sunucu önce selamlaşıyor, ardından sunucu sertifikasını gönderiyor, istemci sertifikayı onayladıktan sonra sertifika içindeki açık anahtarla bir oturum anahtarı oluşturuluyor ve iletişim bu anahtarla şifrelenerek yapılıyor. HTTPS ile olan bu benzerliğin en önemli farkı sertifikayı onaylama kısmı oluyor. HTTPS için kullanılan sertifikalar çoğunlukla güvenilen Sertifika Otoriteleri (CAs) aracılığı ile üretildiğinden tarayıcılarımız sertifikaları onaylamak için onları kolaylıkla kullanabiliyor. SSH için kullanılan sertifikalar ise hemen hemen her zaman sunucu tarafında kendinden imzalı bir şekilde üretiliyor. SSH bağlantısının bütün güvenliği bu sertifikanın güvenilir olması üzerine kurulu olduğundan istemcinin bu sertifikayı bir şekilde onaylaması gerekiyor. SSH istemcilerinin sertifikaları onaylamak için farklı seçenekleri var:
Bu aşamada eğer sunucu anahtarının parmak izini bilmiyorsak onaylayabileceğimiz bir şey de yok demektir. İlk aşamada "8iz5L6iZxKJ6YONmad4oMbC+m/+vI9vx5C5f+qTTGDc" gibi bir ifadenin ezberlenmesi imkansız gibi görünse de yapılamaz değil ama oldukça zor olduğunu kabul edelim.
Sunucunun anahtarının parmak izi yerine ondan üretilmiş bir konsol görselini akılda tutmak daha kolay bir seçenek. Eğer ssh'ı "-o VisualHostKey=yes" parametresiyle kullanırsak aşağıdaki gibi bir görsel görüp onu onaylayabiliriz:
Hem sunucu anahtarının parmak izi hem de ondan oluşturulan bu görsel tek yönlü fonksiyonlar kullanılarak üretildiklerinden tamamen aynısı değil de çok küçük (mesela tek karakterlik) bir farkla üretilemezler. Yani tamamını hatırlamasak bile genel olarak aklımızda tutarak bile sertifikayı onaylayabiliriz aslında.
Sunucu anahtarının parmak izinin doğruluğunu bizim yerimize onaylayabilecek bir mekanizma olması işimizi çok kolaylaşmaz mıydı? Sertifikaları kendimiz oluşturduğumuz için bir CA'dan yardım alamıyoruz ama SSH bağlantısını makine adıyla yapıyorsak mecburen kullanmak zorunda olduğumuz DNS sunucuları burada imdadımıza yetişiyor. Makine adına karşılık gelen IP adresini nasıl DNS sunucusuna sorabiliyorsak aynı şekilde sunucu anahtarının parmak izini de sorabiliriz. Bu işlemi de "-o VerifyHostKeyDNS=yes" parametresiyle yapıyoruz. Eğer sunucumuzla ilgili böyle bir DNS kaydı girilmişse aşağıdaki gibi bir cevap alırız sunucudan:
DNS sunucusuna eklenecek tek satırlık bir girdi ile kullanıcılarımıza bu imkanı sunabilecekken neden kullanılmıyor bilemiyorum doğrusu. Belki bu yazıyı okuduktan sonra siz kullanırsınız ;)
Bu yöntemi kullanırken DNS sorgularının güvenilir bir yöntemle gönderilip alınmadığını aklımızdan çıkarmamamız gerekir. DNSSEC ve DNSCrypt çok daha yaygın kullanılması gereken protokoller ama maalesef neredeyse hiç kullanılmıyorlar.
zaman: Mayıs 07, 2017
23 Nisan 2020’de çıkan Ubuntu 20.04 LTS için Canonical, aynı gün onaylanan Raspberry Pi’ların hepsine Ubuntu Server 20.04 için “tam destek” ekledi. Kullanıcılar, Raspberry Pi’lerinde, Canonical’ın düzgün çalışacağını garanti ettiği Ubuntu 20.04’ün yeni özelliklerinin tamamını kullanabilirler.