2018年8月31日金曜日

ディスプレイマネージャ

ディスプレイマネージャは、LiunxをGUIで操作する場合に最初に起動し、ログイン処理とデスクトップ環境の起動を行うプログラムであるらしい。
Linuxを起動すると、次の順番でデスクトップ環境が起動されるということだ。
  1. initまたはsystemdが、ディスプレイマネージャを起動
  2. ディスプレイマネージャが、ログイン画面を表示
  3. ユーザが、ユーザ名とパスワードを入力してログイン
  4. ディスプレイマネージャが、Xサーバとデスクトップ環境を起動
ということは、initまたはsystemdがどのディスプレイマネージャを起動するか知っているはずである。
Ubuntuの場合、ディスプレイマネージャの切り替えは dpkg-reconfigure コマンドを使って行うらしい。
$ sudo dpkg-reconfigure lightdm
lightdmはUbuntu 16.04を最初にインストールしたときのディスプレイマネージャ。現在のディスプレイマネージャはファイル /etc/X11/default-display-manager に格納されている
$ cat /etc/X11/default-display-manager
/usr/sbin/lightdm

キーボードレイアウト

リモートデスクトップ接続するとキーボードレイアウトが英語のままになっているので日本語キーボードレイアウトに変更する。このサイトを参考にやってみた。
$ cd /etc/xrdp
$ (cd /tmp; wget http://w.vmeta.jp/temp/km-0411.ini)
$ sudo cp /tmp/km-0411.ini .
$ sudo ln -s km-0411.ini km-e0200411.ini
$ sudo ln -s km-0411.ini km-e0010411.ini
$ sudo /etc/init.d/xrdp restart
キーボードレイアウトの変更方法については様々なサイトがあったが、円記号や縦棒が入力できなかったりと不完全だったが、上記の方法だと問題なく解決した。

リモートデスクトップ(その2)

前回、Unityリモートデスクトップ環境を構築したが、
  • 管理者アカウントではUnityデスクトップが表示されない
  • 処理が重い
といった欠点があった。そこで、他のリモートデスクトップマネージャを試してみる。

MATEデスクトップ環境の構築

「メイト」ではなく「マテ」と呼ぶらしい。このサイトを参考にしながらMATEデスクトップ環境を構築した。
$ sudo apt install -y ubuntu-mate-desktop
$ sudo reboot
インストールはこれでおしまい。
ローカルマシンのログイン画面はMATEに変わった。ところがログインするとデスクトップはもとのUnityのままだった。リモートデスクトップでhinfoでログインしても前と変わらない。

次に、/etc/xrdp/startwm.shの中身を次のように変更した。
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
mate-session
するとローカルマシンのログイン後のデスクトップは相変わらずUnityのままだが、リモートデスクトップ接続するとデスクトップ画面がMATEに変わった(図1)。
図1 MATEデスクトップ画面
 今回は、リモートデスクトップで接続すると、管理者アカウントでも、作成したアカウントでも、同じようにデスクトップはMATEになった。

リモートデスクトップはXRDPがやっているので /etc/xrdp/startwm.sh を変更すればデスクトップが変わるのはわかるが、ローカルマシンのデスクトップ自体を変更するのはどうすればよいのだろう?

LXDEデスクトップ環境の構築

次はLXDEデスクトップ環境の構築を行う。これもMATEと同様に動作が軽いデスクトップとのことだ。このサイトにしたがってLXDEのデスクトップ環境を構築した。
$ sudo apt install -y lubuntu-desktop
$ sudo reboot
再起動後、ローカルマシンのログイン画面を見るとMATEのままだった。つぎに、/etc/xrdp/startwm.shの中身を次のように書き換えてXRDPを再起動した。
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
lxsession -s LXDE -e LXDE
そして、リモートデスクトップ接続すると次のようなデスクトップが表示された。
図2 LXDEデスクトップ画面
 管理者アカウントでも、作成したアカウントでもちゃんとLXDEデスクトップは表示される。非常に軽い。また、ローカルマシンのデスクトップはUnityのままであることはMATEと同じだった。

Xfce デスクトップ環境の構築

続いてXfceデスクトップ環境をこのサイトにしたがって構築する。
$ sudo apt install -y xubuntu-desktop
$ sudo reboot
次に、/etc/xrdp/startwm.shの中身を次のように書き換える。
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
xfce4-session
そして、リモートデスクトップ接続すると次のようなデスクトップが表示された。
図3 xfce4デスクトップ画面
 XRDPは再起動しなくとも、/etc/xrdp/startwm.shを書き換えるとリアルタイムで反映されるようだ。

Cinnamonデスクトップ環境の構築

 Cinnamonデスクトップ環境をこのサイトにしたがって行う。CinnamonデスクトップはUnity同様にTigerVNCを使うようだ。
まず、次のコマンドでCinnamonをインストールする。
$ sudo apt install -y cinnamon-desktop-environment
$ sudo reboot
/etc/xrdp/startwm.shの中身を下記のように書き換えてリモートデスクトップ接続する。
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
cinnamon-session
あリモートデスクトップ接続すると次のような画面が表示される。
図4 cinnamonデスクトップ画面

ウインドウマネージャー設定ファイル

ウィンドウマネージャー設定ファイルは/etc/xrdp/にある(下図)。
図5 /etc/xrdp/startwm.sh
startwm.sh の拡張子がウィンドウマネージャの種類を表している。例えば、LXDEデスクトップにしたければ次のようにしてstartwm.shを書き換えればよい。

$ cd /etc/xrdp/
$ sudo cp startwm.sh.LXDE startwm.sh

ユーザごとにウィンドウマネージャーを変更するには 

/etc/xrdp/startwm.shは全ユーザのデフォルトウィンドウマネージャの設定スクリプトである。ユーザ個々にウィンドウマネージャを変える場合は、各ユーザのホームディレクトリ内にstartwm.shを作成し、その中に起動したいウィンドウマネージャのスクリプトを記述しておけばよい。

ウィンドwマネージャ startwm.sh
MATE mate-session
Xfce4 xfce4-session
LXDE lxsession -s LXDE -e LXDE
Cinnamon cinnamon-session
Unity /usr/lib/gnome-session/gnome-session-binary --session=ubuntu &
/usr/lib/x86_64-linux-gnu/unity/unity-panel-service &
/usr/lib/unity-settings-daemon/unity-settings-daemon &

for indicator in /usr/lib/x86_64-linux-gnu/indicator-*; do
   basename=`basename ${indicator}`
   dirname=`dirname ${indicator}`
   service=${dirname}/${basename}/${basename}-service
   ${service} &
done

unity

なお、startwm.shの先頭には下記のスクリプトを記述しておかないとメニュー等が日本語表示にならない。
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
ここで /etc/default/locale というファイルの内容は
LANG="ja_JP.UTF-8"
となっており、if文でこのファイルが読み取り可能か(-rオプション)テストし、読み取り可能であればそれをカレントシェル内で実行し、環境変数 LANG と LANGUAGE を export している。これで、環境変数 LANG に ja_JP.UTF-8 が設定されるので、ウィンドウマネージャは日本語で表示される。

ログイン画面の切り替え

様々なウィンドウマネージャをインストールしたが、ログイン画面はMATEのままである。これを他のディスプレイマネージャに変えるにはdpkg-reconfigureを使うらしい。
$ sudo dpkg-reconfigure gdm3
ところが、これを実行すると
/usr/sbin/dpkg-reconfigure: gdm3 はインストールされていません
というエラーメッセージが出る。
ログイン画面を元に戻すにはどうすればよいのだろう。

リモートデスクトップで日本語入力

Ubuntuには入力メソッドとしてFcitxiBusが最初から入っており、日本語入力システム(IME)としてMozcが入っている。ところが、Ubuntuの標準入力メソッドはFcitx+Mozcになっており、iBus+Mozcを使うには別途パッケージibus-mozcのインストールおよびキーボード入力に使うIMEシステムの変更(デフォルトはFcitx)が必要になる。
Ubuntuをインストールしているサーバを直接操作する場合は Fcitx+Mozcの組み合わせで日本語入力を行うことができるが(その場合でも入力メソッドの設定は必要)、リモートデスクトップ経由だとiBus+Mozcの組み合わせでなければ動かない
そこで、ここではリモートデスクトップでiBus+Mozcで日本語入力する設定について説明する。リモートデスクトップとしてMATEを想定しているが、他のウィンドウマネージャでもそれぞれに応じた操作方法を読み替えれば同様にできるであろう。

キーボード入力に使うIMEシステムの変更

まず、システムのアップデートを行い、終わったら再起動する。
sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y
sudo apt autoclean -y
sudo reboot
次にiBus+Mozcの組み合わせで利用できるようにibus-mozcパッケージをインストールする。
sudo apt install -y ibus-mozc
パッケージのインストールが終わったら、リモートデスクトップでUbuntuサーバに接続する。このとき、リモートデスクトップのウィンドウマネージャはMATEを利用する。
図6に示すように、メニューバーから[システム]→[設定]→[ルック&フィール]→[言語サポート]を選択する。
図6 「言語サポート」を起動する
すると、図7に示す画面が出るので、[キーボード入力に使うIMEシステム]を「iBus」に設定して[閉じる]をクリックする。
図7 言語サポート
次にiBusの設定を行う。メニューバーから[システム]→[設定]→[その他]→[iBusの設定]を選択する。「キーボードインプットメソッド(iBusデーモン)が起動していません。起動しますか?」というメッセージが出たら「はい」をクリックする。「iBusはすでに起動しています!・・・」というメッセージが出たらそのまま「OK」をクリックする。
すると、[iBusの設定]画面が表示されるので「インプットメソッド」タブをクリックする(図8)。
図8 iBus設定画面
 [追加]ボタンを押し、[日本語]→[Mozc]と選択して[追加]ボタンをクリックする。これで、インプットメソッドに「日本語-Mozc」が追加される。

日本語入力

 日本語入力を確認するためにデスクトップの何もないところをマウスで右クリックして[ドキュメントの生成]→[空のファイル]を選択する。
図9 ドキュメントの生成
作成されたファイルを開いてカーソルのある位置でマウスの右ボタンをクリックして[入力メソッド]→[iBus(Intelligent Input Bus)]を選択する。これで日本語の入力が可能になる。入力の切り替えは[半角/全角]ボタンで行う。
図10 入力メソッドの選択

問題

この方法でエディタや端末から日本語入力できるようになったが、何故かブラウザから入力できない。入力の切り替えを行って日本語-Mozc状態になっていても半角文字しか入力できない。これは直接Ubuntuサーバを操作する場合には起きないので、XRDPの問題なのかもしれない。


2018年8月28日火曜日

リモートデスクトップ

WindowsからUbuntuサーバにリモートデスクトップ接続ができるように設定する。参考にしたサイトは「Ubuntu 16.04: Unityデスクトップ環境にXRDPで接続する」。
図1 Ubuntu 16.04: Unityデスクトップ環境にXRDPで接続する

TigerVNCのインストール

まずはTigerVNCをインストールする。下記の内容をTigerVNC.shというファイル名で保存して実行権限を与え、実行する。
#!/bin/sh

set -e

# Install TigerVNC.
sudo apt remove -y vnc4server
sudo apt-get install -y git devscripts xserver-xorg-dev

mkdir tigervnc
cd tigervnc

git clone https://github.com/TigerVNC/tigervnc
cd tigervnc/
git checkout ff872614b507d0aa8bfbd09ef41550390cfe658a

ln -s contrib/packages/deb/ubuntu-xenial/debian
chmod a+x debian/rules
sudo apt install -y $(dpkg-checkbuilddeps 2>&1 | \
                        sed -e 's/.*build dependencies://g' -e 's/([^)]*)//g')
fakeroot debian/rules binary
cd ..

sudo dpkg -i ./*.deb || (sudo apt -f install -y && sudo dpkg -i ./*.deb)
cd ..

図2 viエディタを使ってTigerVNC.shを編集
図3にTigerVNC.shの実行結果を示す。
図3 TigerVNC.shの実行結果

XRDPのインストール

続いて sudo apt install -y xrdp でXRDPをインストールする。
図4 XRDPのインストール

/etc/xrdp/startwm.shの編集

参考サイトには、ホームディレクトリに~/.xsessionを作成して下記の内容を書き込むとあったが、ユーザが複数の場合は /etc/xrdp/startwm.sh に下記を追加するとある。
#!/bin/sh

if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi

/usr/lib/gnome-session/gnome-session-binary --session=ubuntu &
/usr/lib/x86_64-linux-gnu/unity/unity-panel-service &
/usr/lib/unity-settings-daemon/unity-settings-daemon &

for indicator in /usr/lib/x86_64-linux-gnu/indicator-*; do
  basename=`basename ${indicator}`
  dirname=`dirname ${indicator}`
  service=${dirname}/${basename}/${basename}-service
  ${service} &
done

unity
 ~/.xsessionは、ログイン時にX Window Systemを利用したアプリケーションを起動するためのシェルスクリプトであるらしいが、複数ユーザの場合はここに記述したスクリプトが起動時に動くようだ。図5に示すシェルスクリプトではunityが起動されるようになっている。

gnome-control-centerの追加

この状態だと、Ubuntuの画面右上の設定アイコン(歯車アイコン)をクリックするとgnome-control-centerが呼び出されるらしい。そこで、gnome-control-centerにunity-control-centerへのシンボリックリンクを張って、設定アイコンが押されたときにunity-control-centerが呼び出されるようにする。
$ sudo ln -s /usr/bin/unity-control-center /usr/bin/gnome-control-center

リモートデスクトップの実行

Windowsのリモートデスクトップ機能を使ってUbuntuサーバに接続した。
図5 リモートデスクトップ接続画面
コンピュータにサーバのIPアドレスを入力して[接続]ボタンを押すと、警告画面が表示され、そのまま進むとXRDPのログイン画面が出る。
図6 XRDPのログイン画面
ユーザ名とパスワードにUbuntuの管理者IDとそのパスワードを入力して[OK]を押すと、図7に示す画面が表示された。
図7 XRDPを使って管理者アカウントでリモート接続したときの画面
これは「ファイル」というUbuntuのアプリケーションの画面でUnityのデスクトップではない。
次に、作成したユーザでリモート接続すると図8に示すようにUbuntuのUnityデスクトップ画面が正しく表示された。
図8 XRDPを使って作成したアカウントでリモート接続したときの画面
 この場合は左側にランチャーが出ているし、右上にもシステムボタンが表示され、これを操作すればログアウトもできる。

XRDPの設定

以上のように、管理者アカウントと作成したユーザアカウントではXRDPでリモートデスクトップ接続したときに表示される画面が違う。その原因を探るためにXRDPではどのような手順でデスクトップ画面が決まるのかを調べてみた。

XRDPの設定ファイルには、sesman.inixrdp.ini の2つがある。いずれも
/etc/xrdp/
にある。
sesman.ini は、XRDPのセッションマネージャの設定ファイルで、セッションマネージャから起動するスクリプトが格納されたファイルを指定する。

[Globals]
ListenAddress=127.0.0.1
ListenPort=3350
EnableUserWindowManager=1
UserWindowManager=startwm.sh
DefaultWindowManager=startwm.sh

[Security]
AllowRootLogin=1
MaxLoginRetry=4
TerminalServerUsers=tsusers
TerminalServerAdmins=tsadmins

[Sessions]
X11DisplayOffset=10
MaxSessions=10
KillDisconnected=0
IdleTimeLimit=0
DisconnectedTimeLimit=0

[Logging]
LogFile=/var/log/xrdp-sesman.log
LogLevel=DEBUG
EnableSyslog=0
SyslogLevel=DEBUG

[X11rdp]
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp

[Xvnc]
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp
param5=-localhost
param6=-dpi
param7=96
この設定ファイルの中で UserWindowManager に設定した startwm.sh がログインスクリプトである。
なお、ログインアカウントごとにログインスクリプトを設定したければ、そのアカウントの ホームディレクトリに startwm.sh を置いて、その中に起動時に実行したいスクリプトを書く。

なぜ管理者アカウントではリモートデスクトップできないのか?

管理者アカウントのホームディレクトリに unity を起動するスクリプトを書いた startwm.sh を置いてみたが結果は変わらず図7のままだった。
なぜ管理者アカウントと作成したアカウントの間でこのような挙動の違いがあるのかわからない。
ネットを検索してみると、Unity(Compiz)の設定を初期化する方法~/.config/dconf/user を削除する方法などいろいろな記事があったが、どれをやっても問題は解決できなかった。
印象としては、XRDP起動時にUnity以外が起動されているような気がしてならない。

他のマシンで試してみた

管理者アカウントでリモートデスクトップ接続するとUnityデスクトップが表示されない件を他のマシンで調べてみた。その結果、一度はUnityデスクトップが表示されたが、その後は表示されなくなった。ということは、今回のこの問題はこのマシン特有の問題ではないのかもしれない。

SSHサーバ

SSHサーバのインストール

sudo apt -y update, sudo apt -y upgrade で最新の状態にアップデート後、sshサーバのインストールを行う。
図1 sshサーバのインストール

SSHクライアントのインストール

続いてSSHクライアントをインストールする。インストールするのはTeratermWinSCPの2つで、いずれもUSBから起動できるようにポータブル版をインストールする。
図2 Tera Term のダウンロードサイト(窓の杜)
図2は、窓の杜からTeraTermをダウンロードする画面。「Tera Term ポータブル版」の方をUSBメモリへダウンロードする。
図3 WinSCP のダウンロードサイト
図3は、OSDNからWinSCPをダウンロードする画面。「最新ダウンロードファイル」から WinSCP-5.13.3-Portable.zip をダウンロードする。

SSHサーバへの接続

Tera Term

ダウンロードしたTera Term (teraterm-4.99.zip) をUSBメモリ上で展開して、フォルダ内にある ttermpro.exe をダブルクリックして実行する。すると、図4に示す画面が表示される。
図4 Tera Term の初期画面
ここで、[Host:]にサーバのIPアドレスを入力して[OK]ボタンを押すと、図5に示す画面が表示される。
図5 セキュリティ警告画面
これは、そのサーバに初めて接続した場合に表示されるセキュリティ警告画面で、なりすましサーバに誤って接続するのを防ぐために表示される。ここで、[Continue]を押せば、このサーバを知っているサーバのリストに追加し、以降、このセキュリティ警告画面は表示されない。ここでは[Continue]を押して次へ進む。
図6 Tera Term のログイン画面
図6は、Tera Termのログイン画面である。[User name:]にサーバに登録したアカウントを、[Passphrase:]にパスワードを入力して[OK]ボタンをクリックする。
図7 Tera Termでサーバに接続した画面
図7は、サーバに接続した画面である。ここから様々なコマンドを入力してサーバを操作することになる。

WinSCP

Tera Termを使えばサーバに接続して様々なコマンドを入力してサーバの操作を行えるが、サーバにファイルをアップロードしたりサーバからファイルをダウンロードしたりするのはできないことはないけれどあまり得意ではない。
そこで、ファイルのアップロード/ダウンロード専用のSSHを用いたフリーソフトであるWinSCPを用いる。

ダウンロードしたZIPファイル(WinSCP-5.13.3-Portable.zip)を展開した フォルダ(WinSCP-5.13.3-Portable)内にあるWinSCP.exeをダブルクリックして実行すると、図8に示す画面が表示される。
図8 WinSCPの初期画面
左のリストの先頭にある「New Site」をクリックして、右の画面に以下の項目を入力する。
  • Host name: サーバのIPアドレス
  • User name: サーバに登録したユーザID
  • Password: そのパスワード
これらを入力したら[Login]ボタンを押す。
図9 警告画面
 これは、図5で Tera Term の時に出たものと同じで、初めて接続したサーバを登録するかどうかを尋ねる画面である。[Yes]を押せば、サーバは登録され、次からは出ない。
図10 WinSCPがサーバに接続した画面
図10は、WinSCPを使ってサーバと接続した画面である。左側のリストがクライアント、右のリストがサーバである。ドラッグ&ドロップで簡単にファイルのアップロード/ダウンロードが行える。


2018年8月23日木曜日

ユーザ登録

adduserコマンドを使ってユーザ登録を行う。また、登録したユーザには管理者権限を与えるため、sudoグループに加える。
図1 ユーザ登録
登録後、一度ログアウトしてから登録ユーザでログインし、sudoコマンドが利用できることを確認する。

OSのアップデート

OSのインストールが完了したので、次はOSのアップデートを行う。Ubuntuのアップデートにはaptコマンドを使う。
図1 aptコマンドによるOSのアップデート
 ところが、エラーが発生して異常終了する。
図2 アップデートのエラー
 このエラーは原因がわかっていて、初めてアップデートしたときには必ず起きるらしい。対処方法は、appstreamをいったん無効化してからアップデートを行い、その後再びappstreamを有効にすればよいらしい。
図3 appstreamの無効化
 参考にしたサイトには、最初にapt.systemd.dailyを停止(kill)するように書いてあったが、図3に示すように「そのようなプロセスはない」というメッセージが出た。これはどうやら自動アップデートプロセスらしいのだが、それが動いていないということだろう。
 appstreamは、/etc/apt/apt.conf.d/50appstreamという設定ファイルがあると有効になるみたいなので、ファイル名を変更して(拡張子に.disableを付ける)無効化する(図3)。その後、再びsudo apt update -yでアップデートを行う。
図4 アップデートの完了
 アップデートが正常終了したら、次にアップグレードを行う。
図5 アップグレードの完了
 アップグレードが完了したので、設定ファイルの名前を元に戻して再びアップデートを行ってみた。
図6 再度アップデートを行ったときの画面
 今度はエラーが出ることもなく「パッケージはすべて最新です。」と表示され、アップデート処理が完了した。

アップデート処理の途中、マウスが動かなくなったりキーボードが使えなくなったりすることが何度かあった。しばらく何もしないで時間を置くと、次にマウスやキーボードを操作してもすぐに反応しないという現象が見られるが、しばらく待っていると再び自然復旧する。
 また、キーボードの応答がすこぶる悪いため、同じ文字が複数回入力されたりすることがある。そのため、ログイン画面でパスワードが正確に入力できず、何度もログインエラーが表示されることがある。

OSのアップデートが完了したのでシステムを再起動した。再起動後、ログインするとシステムプログラムエラーが出た。
図7 システムプログラムの問題
 このエラーはこれまでも何度も出ていたが、その都度無視してきた。同じ現象について書かれているサイトがあったので読んでみたが、対処方法が書かれてあるだけで、特に原因らしきものは書かれていなかった。

時刻の同期

Ubuntuが時刻同期するNTPサーバはデフォルトでntp.ubuntu.comになっているので、これをntp.ring.gr.jpに変更する。NTPサーバの設定ファイルは/etc/systemd/timesyncd.confなので、これをgeditで編集する。
図8 NTPサーバの設定ファイルを編集するためにエディタgeditを起動
エディタが起動したら設定ファイルにntp.ring.gr.jpを設定して保存する。
図9 NTPの設定ファイルを編集
保存後、再起動して確認する。このとき、geditで保存するといくつかwarningメッセージが出た。
図10 geditの警告メッセージ
 メッセージの内容から、どうやら/home/hinfo/.config/ibus/busの持ち主がrootでないということらしい。
とりあえずそのまま再起動すると時刻の同期ができた。
図11 時刻同期の確認
前述のエラーについて、ネットで調べたところ、sudo gedit は使うべきでないとあった。特権ユーザでGUIツールを使う正しいやり方は sudo -i もしくは gksudo を使うことのようだ(参考サイト)。

【TIPS】

図11の時刻同期の確認で次のようなエラーメッセージが出た場合の対処方法について記載する。
$ sudo systemctl status system-timesyncd.service
● system-timesyncd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
以下のコマンドを入力するとよい(参考サイト)。
sudo systemctl enable systemd-timesyncd.service
sudo systemctl start systemd-timesyncd.service
その後、以下のコマンドを入力する。
sudo systemctl status systemd-timesyncd.service
図12 時刻同期のエラー対処

また、別の方法として、以下のコマンドがある。
sudo timedatectl set-ntp true
その後、次のコマンドで時刻を確認する。
sudo timedatectl status
実行結果を図13に示す。
図13 時刻合わせの別の方法
 こちらの方が結果が見やすい。

Linuxのシステム時刻 

Linuxシステムの時刻というサイトに詳しくまとめられている。
調べていくうちにわかったこと。

自動起動設定

  • Ubuntu14.04まではSysVinit
  • Ubuntu16.04からはsystemd
systemdではsystemctlを使ってサービスの制御(開始、終了、状態表示、有効化、無効化)を行う。

timedatectl

システムのタイムゾーンの設定/再設定を行うコマンド(Ubuntu 14.04でも動作した)

2018年8月21日火曜日

画面が消える

RGBインターフェースのトラブル

やっとインストールできたので、早速ネットワークの設定をしようとUbuntuにログインした。ところが、デスクトップ画面でマウス操作をするとなぜか画面が消える。ディスプレイ装置のLEDがオレンジになっているから信号が送られていない。しばらくしてディスプレイ装置に画面が表示されたが、マウスを操作するとまた消える。そのうち何も表示されなくなってしまった。
このとき、ベアボーンとディスプレイはアナログRGBケーブル(D-Sub15)でつないでいた。どうも、このベアボーンはRGBインターフェースが不安定なようだ。
このベアボーンにはHDMIのインターフェースもあったので、HDMI→VGA変換器(ICZI HDMI-VGA(D-SUB)変換アダプタ)を使ってディスプレイ装置に接続すると画面が消えることはなくなった。
この現象は、今使っているベアボーンだけの問題なのか、それともNUC6CAYHの問題なのか確かめていないが、念のためこの変換アダプタを実験に使うだけの数購入することとした。メモリと言い、ディスプレイと言い、このベアボーンンには本当に悩まされる。これまで使ってきたベアボーンは何事もなくインストールできたというのに・・・。

ネットワークの設定とそこで出た問題

ディスプレイの問題が解消したところで、いよいよネットワークの設定を行う。
まず、ベアボーンにLANケーブルを差し込んでから[システム設定]を起動する。
図1 システム設定画面
続いて[ネットワーク]をクリックする。
図2 「ネットワーク」の設定画面
[有線]を選択して(デフォルトで選択されている)[オプション]をクリック。
図3 「有線接続1の編集」画面
[有線接続1の編集]画面が現れたら[IPv4設定]タブを開き、[方式]を「手動」にして、[Add]ボタンをクリックしてアドレスを入力する。アドレス(IPアドレス、ネットマスク、ゲートウェイ)を入力したら、DNSサーバーのアドレスとドメイン名も入力する。
図4 アドレスを追加
入力を終えたら[保存]ボタンを押す。ネットワークの設定が終わったのでTerminalでifconfigをしてみた。
図5 ifconfigの結果
 案の定、設定は有効になっていない(LANアダプタのデバイス名はenp3s0)。そこで、ベアボーンをリブートした。

すると、ここでもまたはまってしまった。リブートするとシステムが落ちるまでかなりの時間がかかる(数分)。そして再起動を始めても画面に何も表示されない。うっすらUbuntuの特徴的なえんじ色が見えるのでOSは起動しようとしているのだろう。ところが待てど暮らせどログイン画面が表示されない。そこで、しびれを切らして電源を長押しして強制的に落としてから再び電源を投入。しばらく待ってログイン画面は出たものの、ログインすると「システムプログラムの問題が見つかりました」というメッセージ。
そのうちマウスが動かなくなってしまい、再び長押しで電源を落とし、Ubuntuの再インストールからやり直す羽目に陥った。

これまでもUbuntuが固まって(固まったように見えて)長押しで電源を落とすことが何度もあったが、これはやるべきではないのかもしれない。
今回はネットワークの設定を変更したわけだが、そのため、いろいろな付加的な処理が発生して、それに時間が取られていただけなのかもしれない。にもかかわらず強制的に電源を落としたため、システムに問題が発生したのかもしれない。
今となっては想像するしかないが、長押しは最後の手段と肝に銘じておこう。

Ubuntuを再インストールして、ネットワークの設定を行うと、今度は再起動してもちゃんとログイン画面が現れた(さっきは何だったんだろう・・・)。ログインしてターミナルでifconfigコマンドを入力してネットワーク設定を確認した。

図6 ifconfigでネットワーク設定を確認
今度はちゃんとネットワークの設定ができていた。試しにpingを打ってみる。
図7 IPアドr巣を指定してping
IPアドレスを指定してpingを打ったところ、確かに応答が返ってきている。ネットワーク接続成功!
更に、googleのホスト名を指定してpingすると、これまた応答が返ってきている。
図8 googleへping
ということはDNSの設定もOK。
これでネットワークの設定は終了!

おまけ

これでうまくいったと思いきや、一晩寝かせて翌日ログインすると、なんとまた[システムプログラムの問題が見つかりました]が出ているではないか!
図9 問題が見つかりました

「残念ながら、Ubuntu 16.04 で内部エラーが発生しました。」の「詳細を表示」をクリックすると次のような画面が現れた。
図10 詳細エラーメッセージ
何やらいろいろ書かれているが・・・よくわからない。
取り合えあず開いているダイアログを閉じて様子を見てみたが、その後エラー画面は出ていない。これまた何だったんだろう。

このベアボーンには泣かされる

今回のインストール作業ではさんざんベアボーンに泣かされっぱなし。メモリの次はディスプレイ、そしてその次はネットワーク設定にエラー画面。新しいことをすると必ず何か起きる。何事もなくうまくできたためしがない。勉強にはなるが、これで本当に実験が成立するのだろうか?大混乱で終わってしまいそう・・・。




OpenDolphinとORCAの連携

第3章の章末問題 第2章の章末問題でやったカルテ例1をOpenDolphinに入力してORCAで診療報酬明細書を作成し、模範解答と比較しなさい。 を実際にやってみたのでまとめておく。 OpenDolphinで過去にさかのぼってカルテは作成できるか? その前に標題に...