Shammer's Philosophy

My private adversaria

ムームードメインで取得したドメインをRoute53(Amazon DNS Cloud)で管理する

DNSがどのように動作するのか、実際に勉強してみたいと思って自分のドメインを取得したが、、、その勉強をやる前にある程度わかってしまい、勉強用途では不要になった。自分でVPSを2つ用意して、それぞれをPrimaryDNSとSlaveDNSとして動作させようと思っていたが、VPSを2つとなると安いところでも月額1コインでは難しい。ということで、AmazonのRoute53を使用してみようと思ったが、ムームドメイン側で指定するNSサーバーの情報はわかるのか気になって調べてみた。以下のサイトを発見。

営業でも簡単!Route 53の基本設定 – サーバーワークスエンジニアブログ

自分がやろうとしていることと全く同じことをやっている人がいた。とりあえず、Route53でZoneを作成してしまえばNSの情報はわかるようだ。これでどうにかできそうだ。

Does NTP work correctly with enabled Tokyo Daylight Saving Time?

I have heard that there is a possibility to start summer time, Daylight Saving Time, at Tokyo within years, around Tokyo Olympic. So I investigated if ntpd would work under daylight saving time at Tokyo.

The ntpd module of almost Linux distributions are referring /etc/localtime, which is a timezone file itself or symbolic link of any timezone files.

root@server:~# file /etc/localtime 
/etc/localtime: timezone data, version 2, 3 gmt time flags, 3 std time flags, no leap seconds, 9 transition times, 3 abbreviation chars
root@server:~#  cat /etc/issue
Debian GNU/Linux 8 \n \l

#

And all zone files are saved at /usr/share/zoneinfo.

root@server:/usr/share/zoneinfo# ls
Africa	    Atlantic   Canada  EST5EDT	Factory  GMT-0	    Iceland  Japan	MST7MDT  PRC	   ROC	      UCT	 WET		    posix
America     Australia  Chile   Egypt	GB	 GMT0	    Indian   Kwajalein	Mexico	 PST8PDT   ROK	      US	 Zulu		    posixrules
Antarctica  Brazil     Cuba    Eire	GB-Eire  Greenwich  Iran     Libya	NZ	 Pacific   Singapore  UTC	 iso3166.tab	    right
Arctic	    CET        EET     Etc	GMT	 HST	    Israel   MET	NZ-CHAT  Poland    SystemV    Universal  leap-seconds.list  zone.tab
Asia	    CST6CDT    EST     Europe	GMT+0	 Hongkong   Jamaica  MST	Navajo	 Portugal  Turkey     W-SU	 localtime
root@server:/usr/share/zoneinfo# 

Some of zone has 2 files, for example, EST and EST5EDT. One is DST timezone file, and the other is not DST timezone file. Those of them are binary file and I'm not sure how to read it. But, Tokyo zone file is only one.

root@server:/usr/share/zoneinfo# ls Asia/
Aden	   Baghdad  Calcutta	Dhaka	     Hong_Kong	Kamchatka    Kuala_Lumpur  Muscat	 Pyongyang  Seoul	   Tel_Aviv	  Urumqi
Almaty	   Bahrain  Chita	Dili	     Hovd	Karachi      Kuching	   Nicosia	 Qatar	    Shanghai	   Thimbu	  Ust-Nera
Amman	   Baku     Choibalsan	Dubai	     Irkutsk	Kashgar      Kuwait	   Novokuznetsk  Qyzylorda  Singapore	   Thimphu	  Vientiane
Anadyr	   Bangkok  Chongqing	Dushanbe     Istanbul	Kathmandu    Macao	   Novosibirsk	 Rangoon    Srednekolymsk  Tokyo	  Vladivostok
Aqtau	   Barnaul  Chungking	Gaza	     Jakarta	Katmandu     Macau	   Omsk		 Riyadh     Taipei	   Tomsk	  Yakutsk
Aqtobe	   Beirut   Colombo	Harbin	     Jayapura	Khandyga     Magadan	   Oral		 Saigon     Tashkent	   Ujung_Pandang  Yangon
Ashgabat   Bishkek  Dacca	Hebron	     Jerusalem	Kolkata      Makassar	   Phnom_Penh	 Sakhalin   Tbilisi	   Ulaanbaatar	  Yekaterinburg
Ashkhabad  Brunei   Damascus	Ho_Chi_Minh  Kabul	Krasnoyarsk  Manila	   Pontianak	 Samarkand  Tehran	   Ulan_Bator	  Yerevan
root@server:/usr/share/zoneinfo# 

So, at the current release, there is no way to enable DST in Tokyo on the ntpd, I believe.

Enable VM tag vlan on ESXi

According to this site, ESXi supports 3 patterns vlan. 1st is Virtual Switch tagging, 2nd is External Switch tagging, 3rd is Virtual Guest tagging.

Virtual Switch tagging

In this environment, ESXi physical NIC sends out packets with vlan tagging. Then, GuestVMs receive a packet without vlan tagging from ESXi physical NIC. So,

  • GuestVMs don't require vlan tagging configuration on Guest OS layer
  • External Switch opposite of ESXi should be configure vlan tag

External Switch tagging

With this configuration, all physical interfaces are untagged on ESXi. ESXi physical NIC and GuestVMs receive a untagged packet only from external switch. External Switch should be configured to send untag packets to ESXi.

Virtual Guest tagging

Configuring vSwitch vlan ID as 4095 enables that GuestVMs can receive all tagged vlan packets. 4095 seems to mean as vlan tagging pass through. I have never tried this but I want to try in the future.

Japanese Locale Configuration

I wrote an article about Debian locale configuration at Debian Locale Configuration - 20180613 - Shammerism, this is based on LANG=C.
Here is a procedure how to configure Japanese locale.

  1. Edit /etc/locale.gen and remove comment of the line which you want to use
  2. Exec locale-gen
  3. export LANG=$LOCALE_YOU_WANT_TO_USE
  4. export LC_ALL=$LANG
  5. locale-gen --purge $LANG
  6. dpkg-reconfigure -f noninteractive locales
  7. update-locale LANG=$LANG LC_ALL=$LANG
  8. perl -v

If no locale errors happened when perl -v, it is okay.
Here is a sample of /etc/default/locale to use ja_JP.UTF-8 as locale.

LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8

Debian Locale Configuration - 20180613

I wrote an article about the Debian locale in Debian Locale Configuration - Shammerism, but I noticed /etc/environment is not recommended, it is a likely old configuration file. Now we should use /etc/default/locale.
This is a sample using C as a default locale.

LANG="C"
LC_ALL="C"
LC_CTYPE="C.UTF-8"

How to resolve package dependency errors after upgrade from wheezy to stretch?

I upgraded wheezy to stretch with apt-get like below.

  1. edit /etc/apt/sources.list, change distribution strings "wheezy" to "stable"
  2. apt-get upgrade
  3. apt-get dist-upgrade

New sources.list is below.

#deb http://ftp.jp.debian.org/debian/ wheezy main
deb http://ftp.jp.debian.org/debian/ stable main
#deb-src http://ftp.jp.debian.org/debian/ wheezy main
deb-src http://ftp.jp.debian.org/debian/ stable main

But, apt-get update always filed with the following messages after upgrade.

# apt-get update
ヒット http://ftp.jp.debian.org stable Release.gpg
ヒット http://ftp.jp.debian.org stable Release
ヒット http://ftp.jp.debian.org stable/main Sources
ヒット http://ftp.jp.debian.org stable/main amd64 Packages
ヒット http://ftp.jp.debian.org stable/main Translation-ja
ヒット http://ftp.jp.debian.org stable/main Translation-en
パッケージリストを読み込んでいます... 完了         
W: Ignoring Provides line with DepCompareOp for package libapt-inst
W: Ignoring Provides line with DepCompareOp for package libapt-pkg
W: Ignoring Provides line with DepCompareOp for package libespeak-dev
W: Ignoring Provides line with DepCompareOp for package libespeak1
W: Ignoring Provides line with DepCompareOp for package libgpgme11-dev
W: Ignoring Provides line with DepCompareOp for package kodi-api-guilib
W: Ignoring Provides line with DepCompareOp for package kodi-api-pvr
W: Ignoring Provides line with DepCompareOp for package libparse-cpan-meta-perl
W: Ignoring Provides line with DepCompareOp for package libjpeg62
W: Ignoring Provides line with DepCompareOp for package lsb
W: Ignoring Provides line with DepCompareOp for package lsb-core
W: Ignoring Provides line with DepCompareOp for package php-psr-log-implementation
W: Ignoring Provides line with DepCompareOp for package php-seclib
W: Ignoring Provides line with DepCompareOp for package php-sabre-http
W: Ignoring Provides line with DepCompareOp for package php-math-biginteger
W: Ignoring Provides line with DepCompareOp for package pkg-config
W: Ignoring Provides line with DepCompareOp for package pypy-cffi
W: Ignoring Provides line with DepCompareOp for package pypy-cffi-backend-api-max
W: Ignoring Provides line with DepCompareOp for package pypy-cffi-backend-api-min
W: Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-max
W: Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-min
W: Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-max
W: Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-min
W: Ignoring Provides line with DepCompareOp for package sagenb-export
W: Ignoring Provides line with DepCompareOp for package sagenb-export
W: これらの問題を解決するためには apt-get update を実行する必要があるかもしれません

Tried apt-get -f install, but I couldn't get out this loop and couldn't find the way to resolve with apt-get.
At last, I resolved this with doing "aptitude safe-upgrade" repeatedly. The time might come to migrate aptitude from apt-get.

SSH access failure with "Too many authentication failures for $USER"

I don't remember since when correctly, but I faced with the problem ssh access failure with the message "Too many authentication failures for $USER". There is no problem if trying ssh access from other host, it is the problem only my main Mac.

I found the debug option of ssh, using -v, then this determination would be done after the public key authentication failure, but I don't want public key authentication to this site. Here is a part of ssh debug output when do "ssh -v user01@X.X.X.X".

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user01/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering DSA public key: /Users/user01/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/user01/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/user01/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/user01/.ssh/id_ecdsa
debug1: Trying private key: /Users/user01/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Received disconnect from X.X.X.X: 2: Too many authentication failures for admin

I want to do public key authentication against specific hosts, but not all. This server is not my target of public key authentication. In this case, disabling public key authentication with the ssh command line option. The command line parameter "-o PubkeyAuthentication=no" should be used.