27.09.2017

takas bölümünü etkinleştirmek

Mevcutta bir linux kurulumuna sahip bir makineye ikinci bir linux yüklüyorum. İkinci linux için partition hazır. Ama takas (swap) bölümünü diğer linux kurulumu ile paylaşmak istiyorum. Çok yüksek güvenlikli bir sistem olsaydı bunu yapmamak lazım. Ama kullandığım öyle bir sistem değil ve bunu yapmak mümkün.

İkinci linuxun kurulumu sırasında sda7'yi / (kök) olarak mount etmeyi seçtim, ama swap için bir partition seçmedim. Seçersem bu partition'ı formatlayacak, ve diğer linuxun bu disk bölümüne bağlantısı kopacak.

İkinci linuxun kurulumu tamamlandıktan sonra

$ free
          total     used      free    shared    buff/cache   available
Mem:     1828852    796260    445196   141164     587396        627628
Swap:       0          0         0

yazarak sistemin herhangi bir swap kullanmadığını (Swap satırındaki değerler tümü 0) doğruladım. Mevcut sistemdeki takas bölümünün (swap partition) hangisi olduğunu bulmak için fdisk'i kullandım:

$ sudo fdisk -l

Bu komutun çıktısında türü Linux takas olarak listelenen tek bölümün sda8 olduğunu gördüm. Birinci kurduğum linux zaten bu bölümün yapılandırmasını yaptığı için

$ sudo mkswap /dev/sda8

yapmama gerek kalmadı. Eğer ilk defa yapılandırıyor olsaydım bu komutu kullanmam gerekecekti. Bölüm hazır olduğu için doğrudan

$ sudo swapon /dev/sda8
Komutu ile takas alanını etkinleştirdim. Bunu doğrulamak için

$ free
           total        Used      free     Shared   buff/cache       available

Mem:       1828852     796260    445196    141164   587396             627628
Swap:      3771388         0    3771388


Komutunu kullandım. Son satırda total sütununda swap'ın sıfırdan farklı bir değerde olması yeterli.

Yalnız bu, bir sonraki açılışta takas bölümünün tekrar bağlanacağını garantilemiyor. Bunu garantilemek için /etc/fstab dosyasına ilgili girişin yapılması gerekiyor. Yeni linux sistemlerinde disk bölümlerine UUID'ler ile erişiliyor. Mevcut disk bölümlerinin UUID'lerine erişmek için blkid komutunu kullanmak gerek.

$ sudo blkid
Bu komutun sonunda /dev/sda8 bölümüne ait UUID'yi kopyalayarak /etc/fstab dosyasına şu şekilde girdim:

UUID="....."        swap          swap        defaults     0  0

Ayrıca açılış sırasında değien UUID sebebiyle "manjaro hibernation device not found" gibi bir hata da alınabilir. Bu durumda yapılacak swap alanının UUID'sini kopyalayıp /etc/default/grub dosyasındaki resume=GUID=<...> kısmına girmektir. Bundan sonra da update-grub ile bu durumu etkin grub menüsünde yansıtmak.

Bir sonraki açılışta free komutu ile takas bölümünün mount edildiğini doğruladım, konu kapandı.

24.09.2017

xfce masaüstü özelleştirmeleri

Fedora xfce spin kullandığım bir dizüstü bilgisayarda ses açma / kapama ve medya tuşlarının (durdur, ileri, geri gibi) çalışmadığını farkettim. Bu duruma şu şekilde bir çözüm buldum:

Klavye ayarlarına girerek kısayollar sekmesine geçtim. Önce bir terminal penceresinde şu komutların ses açma / kapama görevi görüp görmediğini denedim:

amixer set Master 10000+
amixer set Master 10000-
Bu komutların işe yaradığını görerek klavye kısayollarına yeni tuşuna basarak bu komutları birer birer ekledim. Bittikten sonra da klavyedeki ilgili düğmeye basarak atamayı tamamladım.

Ses kapatma (mute) işlevi için de

amixer set Master toggle

komutunu kullandım. Profilimin altına .Xmodmap diye bir dosya oluşturmak ve içine

keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext

ekleyerek xmodmap .Xmodmap komutunu çalıştırmak işe yaramadı maalesef.

Medya tuşları için kısayollar pragha uygulamasına atanmıştı. Kullanmadığım bir uygulamaydı,

sudo dnf remove pragha

komuduyla bu uygulamadan kurtuldum. Ama klavye kısayollarında bu kaldı. Bu kısayolları Spotify ile kullanabilmek istiyordum. Bu girişleri çift tıklayarak durdurma için
dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
komudunu kullandım. Karşısındaki XF86AudioPlay durum için uygundu; dokunmadım. Sonraki şarkıya geçiş için
dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next
komudunu kullandım. Karşısındaki XF86AudioNext durum için uygundu; değiştirmedim. Önceki şarı geçişi için
dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Previous
komudunu kullandım. Bunun karşısındaki XF86AudioPrev de uygundu, değiştirmedim.

Şu anda Spotify'ı sorunsuz olarak kullanabiliyorum.

Ayrıca şifre ekranındaki duvar kağıdını değiştirebileceğim bir yer de bulamıyordum. Bunun çözümünü de şöyle buldum:

/etc/lightdm/ klasörünün altındaki lightdm-gtk-greeter.conf dosyasını root ile (ya da sudo) açıp [greeter] başlığının altındaki background öğesinin değerini değiştirdim. Yalnız profilimin altındaki bir yolu göstermem çözüm olmadı. Bunun için istediğim dosyayı da /usr/share/background/ klasörüne kopyaladım.

16.01.2017

Fedora'da i ve ı harflerini basamamak

Fedora'yı 24'ten 25'e yükseltince i ve ı harflerini (küçüç/büyük) basamadığımı farkettim. Arama yaptığımda bu sorunun aslında 22'den beri olduğunu, ancak bazı donanımlarda ortaya çıktığını gördüm. Gerçi benim makinemde birkaç sürümdür kuruluydu Fedora ama nedense 25. sürümde ortaya çıkmaya karar vermiş. Çözüm olarak Wayland'i GDM için devre dışı bırakmaktan bahsedilmiş. Bunun için tercih edilen metin editörünüzü root ile çalıştırdıktan sonra
/etc/gdm/custom.conf 

dosyasını açarak
#WaylandEnable=false
satırının başındaki # işaretini kaldırarak
WaylandEnable=false
haline getirip kaydetmek ve sistemi tekrar başlatmak gerek. i harfine basamadan favori metin editörümü root ile başlatmak için biraz yaratıcılığımı kullanmam gerekti :)

Bunun uzun vadede ne gibi sonuçları olacak, bilmiyorum. Gelecekte bir ara bunu değiştirmek gerekebilir ama sürüm 22'de bile aynı hataların alındığını görünce bunun pek kısa vadede olacağını da sanmıyorum.

5.01.2017

Windows ve Bellek

Windows'da bellek kullanımı konusu oldukça karmaşık bir konudur. Görev Yöneticisinde yer alan sanal bellek, çalışan küme, takas dosyası gibi terimler kafaları karıştırabilir. En basitinden bir programın işletim sisteminden ne kadar bellek talebinde bulunduğunu nasıl anlayabiliriz?

Windows'da genel olarak bellek konusu sadece fiziksel bellek (RAM) ile sınırlı değildir. Ana kartın bellek yuvalarına takılan RAM ünitelerinden bağımız olarak, çalışan her süreç için geniş bir sanal adres alanı sunulur. 32-bitlik sistemlerde bu 2 GB, yeni 64-bitlik sistemlerde ise bu çok daha fazladır (128 GB gibi). Bu sanal bellek elbette. Her çalışan program 128 GB bellek kullanabilir demek değil.

İşletim sisteminde ise belli bir sınıra kadar çalışan süreçlere bellek tahsisi yapılabilir. Bu sınır da makinedeki RAM ile takas dosyası boyutunun toplamı kadardır. Bu değere kaydetme sınırı (commit limit) denir.

Diyelim ki Word'ü açtık ve uzunca bir belge hazırladık. İçine de bir sürü resim ekledik, tablolar falan... Derken sayfalarca uzunluğunda bir belge oluştu. Bunu yaparken uzun bir süre harcadık. Nihayetinde Word yazdığımız tüm içeriği kaybetmememk için işletim sisteminden sürekli bellek talebinde bulundu, bunları hafızada tuttu. Bunu yaparken de arka planda diyelim ki müzik dinliyorduk, Firefox'ta bir sürü sekme açıktı, ayrıca bir sürü başka program da açıp kapattık, bellek ihtiyacı sadece Word ile sınırlı kalmadı. Bu sürede bilgisayar Word için ayrılan bellek miktarının bir kısmını boşaltarak diğer uygulamalara verir. Ancak Word'ün verilerini de kaybetmemek için onları takas dosyasına yazar. Bu işi yaparken de en eski oluşturulmuş, en uzun süre önce üzerinde işlem yapılmış bellek alanlarını seçer. Word tekrar bu verilere ihtiyaç duyduğu anda ise bu bellek alanı takas dosyasından okunarak tekrar belleğe alnır; muhtemelen başka programların uzun süredir kullanılmayan verilerini yine takas dosyasına kaydederek.

Burada şu ayrımı yapmak gerek; Word ile çalışırken verilerin bir kısmı bellekte tutuluyordu, diğer bir kısmı da takas dosyasında tutuluyordu. Başka programlar için de aynı şey geçerli. Firefox yeni açtığım sekmeye ait verileri bellekte tutarken, ilk açtığım sekmedeki verileri takas dosyasına atmıştı. Bu süreçlerden her biri sanal bellek alanında 2 GB'a kadar (32 bitlik bir sistem olduğunu farzedersek) adresleme yapıyor olabilir, ancak her süreç için bellekte ayrılabilecek o kadar alan olmayabilir. Bu durumda bu 2 GB'lık sanal bellek alanındaki verilerin bir kısmı bellekte değil, takas dosyasında tutuluyor olabilir.

Ayrıca Word bazı sistem özellikerini kullanabilmek için (pencereyi çizebilmek, yapılandırma diyaloglarını görüntüleyebilmek, yazıcıdan çıktı alabilmek vs) bazı sistem dll dosyalarını yükleyecek ve kullanacaktır. Bu veriler diğer süreçlerle paylaşılan bir bellek alanı oluşturur.

Bu noktada bazı bellek terimlerini isimlendirelim:

Çalışma kümesi (working set) : Süreç tarafından işletim sisteminden talep edilen ve henüz bellekte tutulan (takas dosyasına gönderilmemiş) alan ile paylaşılan (dll dosyaları gibi) veriler. Bu alanda hem sürece özel üretilen veriler hem de paylaşılan kodlar depolanır.

Ayırma boyutu (commit size) : Bu ise programa tahsis edilen tüm sanal bellek miktarını gösterir. Bu veriler paylaşılmış veriler değil, diğer süreçler tarafından erişilemeyen, bu süreç tarafından üretilen özel verilerdir. Çalışma kümesinden farklı olarak bu rakama dahil olan bellek alanlarının tümünün RAM'de tutulduğunun garantisi yoktur. Eski verilerin bir kısmı takas dosyasına gönderilmiş olabilir. Bu alanda paylaşılan kodlar depolanmaz.


Yukarıdaki ekran görüntüsünde de notepad.exe sürecinin kullandığı bellek alanını inceleyelim. Bu resimde bellek ile ilgili iki sütun görüntüleniyor; Çalışma Kümesi ve Ayırma Boyutu. Notepad.exe için Çalışma Kümesi sütununda gösterilen 12.744 KB veri doğrudan RAM üzerinde tutulan not defteri verisi. Ancak buna paylaşılmış bellek (dll gibi) de dahil. Ayırma Boyutu sütununda gösterilen rakam ise not defteri tarafından ihtiyaç duyulan tüm veri miktarını gösterir. Bunun bir kısmı takas dosyasında olabilir, ancak bu rakama paylaşılan bellek miktarı dahil değildir.

Bu alanlara ek olarak Windows 7 ve sonrası sürümlerde gelen "Özel Çalışma Kümesi" alanı var. Bu alana paylaşılan bellek miktarı dahil değil. RAM'de saklanan sürecin özel verilerini gösteriyor. Bu alanı görebilmek için menüden Görünüm>Sütun Seç ile Bellek-Özel Çalışma Kümesi'ne ait kutuya işaret koymamız gerek.


Görüldüğü gibi not defteri için (seçili satır) özel çalışma kümesi de 7.948 KB. Çalışma Kümesi alanından bu veriyi çıkartarak 4.797 KB'lık veri paylaşılan bellek miktarı oluyor. Not defterin ayrılan toplamda 8.216 KB'lık verinin ne kadarı takas dosyasına atılmış olabilir? 8.216'dan 7.948'i çıkararak bulabileceğimiz 268 KB da "muhtemelen" takas dosyasına atılan miktar olabilir. Muhtemelen diyorum, çünkü süreçlere ait uzun süredir kullanılmayan alanlar hemen takas dosyasına gönderilmez. Bir süre daha belleğin bekleme alanında bekletilir, tekrar ihtiyaç duyulma ihtimaline karşı. Bir süre sonraki durak elbette takas dosyası olacaktır.

Bellekteki bu işlemler "sayfa" denen 4 KB'lık bölümler üzerinden yapılır. Tüm bellek 4 KB'lık sayfalara bölünmüştür. Süreç, işletim sisteminden her yeni bellek talep ettiğinde bu sayfaların katı miktarda alan tahsis edilir. Bellekten takas dosyasına veya tam tersi yöndeki taşıma işlemlerinin tümü bu 4 KB'lık sayfa boyutu üzerinden yapılır. Bellekte en uzun süredir kullanılmayan alanlar yine bu sayfa boyutları üzerinden belirlenir. Yani 1 byte'lık bir alan bile talep edilse 4 KB'lık bir sayfa ayrılır. Bu sebeple yukarıdaki bellek verilerinin tümü 4'e bölünebilen sayılardır.

Bir sürecin erişmek istediği veri doğrudan çalışma kümesi içindeyse o verilere doğrudan erişir, veriler veya kodlar farketmez. Ancak veriler ayırma boyutu alanına taşınmışsa onlara doğrudan erişemeyecek, erişim bir sayfa hatasına (page fault) sebep olacaktır. Söz konusu sayfa henüz bekleme alanındaysa (standby memory) bu bir yazılımsal sayfa hatası (soft page fault), aksi takdirde veri takas dosyasına gönderildiyse bir donanımsal sayfa hatasına (hard page fault) sebep olur. Görüldüğü gibi sayfa hatalarının aslında bir hatayla ilgisi yok, tamamen normal bir işleyiş.

Örneğin Word ile hazırladığımız belgenin yazıcıdan çıktısını almak istiyoruz. Menüden yazdır komutunu verdikten sonra sistem yazıcı ile ilgili sistem dosyalarına ihtiyaç duyacaktır. Bu sistem dosyaları bilgisayar açıldığından beri hiç kullanılmadıysa (veya kullanıldıysa ama üzerinden yeteri kadar uzun bir süre geçtiyse ve artık hafızada değillerse) bir donanımsal sayfa hatası oluşur. Veriler diskten okunur, işlevlerin kullanılabilmesi için gereken yordamlar belleğe alınır. Bu miktar çalışma kümesi alanına eklenir. Aradan bir süre geçtikten sonra bu sistem dosyaları için ayrılan alan önce bekleme alanına gider. Tam bu anda tekrar çıktı almak istersek bu sistem dosyalarına yapılan referans için bir yazılımsal sayfa hatası oluşur, diske hiç ihtiyaç duyulmadan işlem tamamlanır. Ama yeteri kadar uzun süre geçtikten sonra tekrar çıktı almak istersek bu bir donanımsal sayfa hatası oluşur. Veriler tekrar diskten okunur. Ama bu veriler paylaşılan sistem dosyalarına ait olduğu için hiçbir zaman takas dosyasına yazılmaz, doğrudan diskten tekrar okunur.


Windows sanal bellek miktarı üzerindek çalışan bir işletim sistemi olduğundan, her bir sürece yapılan sanal bellek atamalarının (ayırma boyutu / committed bytes) toplamı ile çekirdek (kernel) işlemleri için yapılan bellek ayırmaların sayfalanmış (paged) miktarının toplamı sistem toplam kaydetme miktarı (commit charge) ile ifade edilir. Eğer bu miktar sistem ayırma sınırına (system commit limit, yukarıda açıkladığım gibi sistem RAM'i ile takas dosyasının boytunun toplamı) ulaşırsa bellek problemi uyarıları ile karşılaşırız. Takas dosyası otomatik olarak (eğer öyle ayarlandıysa) büyütülmeye çalışılır. Çok nadir de olsa bu gibi durumlarla karşılaşıldığında hangi sürecin bu durumda aşırı bellek kullandığını incelemek gerekebilir.

Çok uzun oldu. Evet, anlaşılması da kolay olmadı, Türkçe terimleri de işin içine katınca. Üzgünüm.

Ek 2022-07-15 : Process Explorer ayırma boyutu (commit size) yerine private bytes terimini kullanıyor. Özet olarak bu veri, program için ayrılan tüm sanal bellek miktarını gösteriyor. Bunun RAM'de tutulan bölümü private working set ile gösterilen miktarı. Workins set ise bu değere paylaşılan bellek miktarını ekleyince ortaya çıkıyor. Nihayetinde bir sürecin işletim sisteminden ne kadar bellek ataması aldığını öğrenmek için private bytes alanına bakmak gerek.

Ayrıca Powershell'de Get-Process cmdlet'inin çıktıları arasında Private Working Set alanı yoktur. Bunu görmek için performans sayaçlarına bakmak gerek.

31.12.2016

Windows parolasını sıfırlamak

Bilgisayarı herhangi bir linux live CD'si ile açıın. Muhtemelen chntpw paketi yüklü değildir. Aşağıdaki komutlarla yükleyin. Öncesinde muhtemelen universe repository'lerini eklemek gerekecek:

sudo add-apt-repository universe

sudo apt-get update
sudo apt-get install chntpw
System partition'ı mount edin:
sudo mount /dev/sda1 /mnt/win
/mnt/win klasörü yoksa önce onu yaratmak gerekir
sudo mkdir /mnt/win
Ardından SAM'in yer aldığı klasöre geçin
cd /mnt/win/Windows/System32/config
Bu klasördeyken aşağıdaki komutu vererek chntpw'i çalıştırın
sudo chntpw SAM
Bu şekilde varsayılan olarak Administrator kullanıcısı üzerinde işlem yapıyor olacağız. Eğer başka bir kullanıcı ile işlem yapacaksak
sudo chntpw -u <username> SAM
komutuyla kullanıcı seçebiliriz. Sistemdeki kullanıcı adlarını görmek için
/mnt/win/Users
klasörünün altındaki profil klasörlerinin isimlerine bakabiliriz. Herneyse chntpw'yi çalıştırında aşağıdakine benzer bir ekran ile karşılaşacağız.


Burada önerilen 1 ile kullanıcı şifresini sıfırlamak (boş olacak). Seçenek 2 pek önerilmiyor. İki komutun ardından da y ile emin olduğumuzu söyleyeceğiz.

Bilgisayarı tekrar başlatıp seçilen kullanıcı ile "boş şifre kullanarak" oturum açabiliriz.
 
---
2019-03-04
 
Başka bir seçenek de şifresi unutulduğu için bir türlü açılamayan bilgilsayarı ya kurulum CD'siyle ya da bir linux live CD'siyle açtıktan sonra C:\Windows\system32 klasöründe bulunan sethc.exe dosyasını sethc_asil.exe olarak yeniden adlandırıp
 
move  sethc.exe sethc_asil.exe
 
cmd.exe'nin sethc.exe adıyla bir kopyasını oluşturduktan 
 
copy cmd.exe sethc.exe
 
sonra bilgisayarı tekrar başlatıp şifre ekranında 5 kez shift tuşuna basarak ya da mümkünse registry'e sethc.exe için bir Image File Execution yönlendirmesi ekleyerek

REG ADD “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe” /v Debugger /t REG_SZ /d “C:\windows\system32\cmd.exe”

de aynı şeyi yapabiliriz. Burada amaç shift'e 5 kez basıldıktan sonra ekrana gelmesi beklenen erişilebilirlik kısayolları yerine komut satırı penceresinin açılmasını sağlamak. Bu pencere system kullanıcısı yetkileriyle açılacağı için Administrator hesabı da dahil olmak üzere tüm hesapların şifresini hiçbir şifre girmeye gerek kalmadan değiştirebiliyor olacağız. Bunu da komut satırından

net user Administrator *yeniparola*
 
komutu ile yapacağız. Hatta

net user YeniKullanici *yeniparola* /add

komutu ile yeni bir kullanıcı ekleyerek de yapabiliriz. Bu yeni kullanıcıyı da yönetici yapmak için

net localgroup Administrators YeniKullanici /Add

komutuyla kullanıcıyı Administrators grubu üyesi yapabiliriz. Pencereyi kapatır kapatmaz giriş yapmak mümkün. Aynı etkiyi sethc.exe yerine Utilman.exe veya osk.exe ile de yapmaktan bahsedilmiş. Bu durumda oturum açma ekranında 5 kez shift'e basmak yerine sırasıyla erişilebilirlik seçeneklerine veya ekran klavyesine geçiş yapmak durumunuz olabilir. StackExchange'de de konuşulduğu gibi Windows 10 için durum biraz daha karışık. Windows Defender'ın bu gibi yöntemleri engellemesi söz konusu olabilir.

2021-12-30 ek: Sami Laiho videosunda Windows Defender engellemesine karşı C:\Programdata\Microsoft\Windows Defender\Platform\x.xx.xxxx.x-x\MsMpEng.exe'nin ismini değiştirerek çalıştırılmasının engellenmesini önermiş.

30.11.2016

ICMP ve TTL değerleri

Bugüne kadar ping sonuçlarını incelerken farklı TTL (Time To Live) değerleri hiç ilgimi çekmemişti. Geçilen her düğümde bu değerin bir düşürüldüğü ve 0'a ulaştığında ise paketin artık daha fazla yönlendirilmediği temel bilgisine sahiptim, ama neden bazen 50-60'lı değerler görürken bazen bu 200+ oluyordu? Acaba arada bu kadar fazla düğüm olması ihtimali var mıydı?

Bugün bu konuya biraz zaman ayırdım. Gördüm ki bu farklılık hedef sistemin yapısıyla ilgilymiş. Ping request işlemini başlatan tarafla hiç ilgilsi yokmuş. Karşı taraftaki işletim sisteminin belirlediği bir değermiş. Farklı işletim sistemlerinin farklı TTL seviyeleri oluyormuş. Şu sayfada ayrıntılı bir liste verilmiş.

Device / OS Version Protocol TTL
AIX TCP 60
AIX UDP 30
AIX 3.2, 4.1 ICMP 255
BSDI BSD/OS 3.1 and 4.0 ICMP 255
Compa Tru64 v5.0 ICMP 64
Cisco ICMP 254
DEC Pathworks V5 TCP and UDP 30
Foundry ICMP 64
FreeBSD 2.1R TCP and UDP 64
FreeBSD 3.4, 4.0 ICMP 255
FreeBSD 5 ICMP 64
HP-UX 9.0x TCP and UDP 30
HP-UX 10.01 TCP and UDP 64
HP-UX 10.2 ICMP 255
HP-UX 11 ICMP 255
HP-UX 11 TCP 64
Irix 5.3 TCP and UDP 60
Irix 6.x TCP and UDP 60
Irix 6.5.3, 6.5.8 ICMP 255
juniper ICMP 64
MPE/IX (HP) ICMP 200
Linux 2.0.x kernel ICMP 64
Linux 2.2.14 kernel ICMP 255
Linux 2.4 kernel ICMP 255
Linux Red Hat 9 ICMP and TCP 64
MacOS/MacTCP 2.0.x TCP and UDP 60
MacOS/MacTCP X (10.5.6) ICMP/TCP/UDP 64
NetBSD ICMP 255
Netgear FVG318 ICMP and UDP 64
OpenBSD 2.6 & 2.7 ICMP 255
OpenVMS 07.01.2002 ICMP 255
OS/2 TCP/IP 3.0 64
OSF/1 V3.2A TCP 60
OSF/1 V3.2A UDP 30
Solaris 2.5.1, 2.6, 2.7, 2.8 ICMP 255
Solaris 2.8 TCP 64
Stratus TCP_OS ICMP 255
Stratus TCP_OS (14.2-) TCP and UDP 30
Stratus TCP_OS (14.3+) TCP and UDP 64
Stratus STCP ICMP/TCP/UDP 60
SunOS 4.1.3/4.1.4 TCP and UDP 60
SunOS 5.7 ICMP and TCP 255
Ultrix V4.1/V4.2A TCP 60
Ultrix V4.1/V4.2A UDP 30
Ultrix V4.2 – 4.5 ICMP 255
VMS/Multinet TCP and UDP 64
VMS/TCPware TCP 60
VMS/TCPware UDP 64
VMS/Wollongong 1.1.1.1 TCP 128
VMS/Wollongong 1.1.1.1 UDP 30
VMS/UCX TCP and UDP 128
Windows for Workgroups TCP and UDP 32
Windows 95 TCP and UDP 32
Windows 98 ICMP 32
Windows 98, 98 SE ICMP 128
Windows 98 TCP 128
Windows NT 3.51 TCP and UDP 32
Windows NT 4.0 TCP and UDP 128
Windows NT 4.0 SP5- 32
Windows NT 4.0 SP6+ 128
Windows NT 4 WRKS SP 3, SP 6a ICMP 128
Windows NT 4 Server SP4 ICMP 128
Windows ME ICMP 128
Windows 2000 pro ICMP/TCP/UDP 128
Windows 2000 family ICMP 128
Windows Server 2003 128
Windows XP ICMP/TCP/UDP 128
Windows Vista ICMP/TCP/UDP 128
Windows 7 ICMP/TCP/UDP 128
Windows Server 2008 ICMP/TCP/UDP 128
Windows 10 ICMP/TCP/UDP 64

Bu konunun özetini de sayfanın altında çıkarmış. Buna göre hedef bir Linux ise TTL'i 64'ten, bir Windows ise 128'den, bunun yanısıra bir Cisco cihazı / Solaris ise 254'ten başlıyormuş geriye sayım.

21.11.2016

VMware'de Linux sanal makineler ve dosya paylaşımı

Linux sanal makineler için eskiden VMware Workstation'da vmtools kurulumu başarılı sonuçlar verirdi, ama artık olmuyor. Bunun yerine artık open-vm-tools paketi öneriliyor. Paylaşım için yapılacaklar; linux kurumu bittikten sonra hiç VMware Tools kurulumuna girmeden, eğer kurulu değilse open-vm-tools paketini kurmak. Birçok dağıtımda zaten kurulu geliyor. Gelmezse
sudo dnf install open-vm-tools
sudo apt install open-vm-tools
ile kurulum yapılabilir. Bu aşamadan sonra VMware Workstation'da evsahibi makinede (host) klasör paylaştırılabilir. Sanal makineden paylaştırılan klasörü görüntülemek için vmware-hgfsclient kullanılabilir.
vmware-hgfsclient
share
Ardından vmhgfs-fuse ile mount etme yapılır
vmhgfs-fuse .host:/share /home/username/folder

Elbette /home/username/folder yolu var olan bir klasör ile değiştirilmeli.

Şu adreste buldum ki şu da

mount -t fuse.vmhgfs-fuse .host:/share /home/username/folder

aynı işi yapıyor. Gösterdiğim kaynak -o allow_other parametresini de kullanmış, ama benim sistemimde /etc/fuse.conf dosyasında user_allow_other set edilmemişti, kaldırdım. Bu bir ihtiyaçsa /etc/fuse.conf dosyasında user_allow_other'ın başındaki # karakteri silinerek bu sağlanabilir. Ayrıca bu mount'un her yeniden başlangıçta tekrar etkin olmasını istersek /etc/fstab dosyasına şunun gibi bir satır girmemiz yeterli:

.host:/     /home/username/folder     fuse.vmhgfs-fuse      allow_other      0 0

allow_other ile ilgili yukarıda söylenenler burada da geçerli.

Var olan bir bağlantıyı kaldırmak için

umount /mnt/hgfs

gerekli.