ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2024年6月14日金曜日

Hyper-Vで終了できなくなったOSを削除する。

仮想マシン上のOSが落ちてしまった

Hyper-Vで作成した仮想マシン、何らかの問題で固まってしまうことがあります
OSは動きっぱなしなのでメモリとかリソースを使ったまま。
動作中の仮想マシンは Hyper-V に削除メニューがありません。
そうなってしまった場合の対処方法についてまとめます。

OSをインストールしたら固まってしまった

今回は、CentOS 6.5 という古いバージョンのしかも32bit版の環境を作る、という目的でした
インストールの手順は省くとして。
最終的に起動後は、こんな状態になってしまい、「停止」とか「シャットダウン」も機能しなくなってしまいました!

Hyper-V では「実行中」と表示されていてメモリを消費しています。
「削除」メニューもありません・・・
このまま放置するとメモリの無駄遣いですね・・・

エクスプローラで、Hyper-V の仮想マシン用フォルダを削除しようとしても、「使用中」で削除できません。

そんなときの対処方法

Hyper-V を停止して、その間にフォルダを削除してから Hyper-V を再開すればいいってことです。

Windows の「サービス」を起動して、「Hyper-V Virtual Machine Management」を見つけましょう

「スタートアップの種類」を「手動」に変更して「適用」を押します。
「停止」ボタンを押してサービスを停止します。
必要ないのかもしれませんが、なんとなく、この時点で Windows を再起動させています。

Windows を再起動させたら、まず、不要な仮想マシンフォルダをエクスプローラで削除します。

削除できました!

サービスを起動して、「Hyper-V Virtual Machine Management」を「自動」にして「開始」します。

Hyper-V を起動してみると、無駄に動作していたOSがなくなっていることがわかります。

まとめ

これ、よくあるんですよねー。
同じように困ってしまったら、上記方法を(自己責任の範囲でw)お試しください。
めでたしめでたし。

2024年5月5日日曜日

PHP の日本語ファイル名処理で文字化け

電子情報保存法に対応

請求書をサーバに保存して電子情報保存法に対応しましょ、という仕組み作りがあちこちで行われているかと思います。
過去の経験から、サーバー上に文書ファイルを保存しようとする場合、日本語のファイル名では保存しない方がいいと思いますよ。
たとえば、濁点、半濁点付きのファイル名「ぱぴぷぺぽ.pdf」ファイルをそのままサーバに保存しておいて、ブラウザでダウンロードできるようにしようとすると
Windows クライアントでは正しく表示できるけど、MacOS では正しく処理できない、といった問題が発生してしまいます。

そこで、サーバに保存するときには、ファイル名を半角英数字のみにして保存するようにしてみました。
ファイル名を拡張子と分離するには、PHP の pathinfo() 関数を使います。
半角英数ファイル名の構造には、BASE64 エンコードと使えない文字を置き換える base64UrlEncode() 関数を使って処理します。

BASE64を使ったエンコード処理

function base64UrlEncode($data) 
{ 
    return rtrim(strtr(base64_encode($data), '+/', '-_'), '='); 
} 

ファイル名の拡張子以外の部分を base64UrlEncode で構築する処理を用意してみました。
入力フィールドで拡張子を指定しなかった場合は、.pdf ファイルだという処理も入れてみています。

function buildFileName($filename, $def_ext = 'pdf')
{
    $file_parts = pathinfo($filename);
    $filenode = $file_parts['filename'];
    $ext = $file_parts['extension'];
    if(strlen($ext) == 0)
    {
        $ext = $def_ext;
    }
    $name = $this->AsCommon->base64UrlEncode($filenode) . '.' . $ext;
    return $name;
}

日本語ファイル名が正しく処理されない

$filename = uildFileName("ぱぴぷぺぽ.pdf");
を実行すると、".pdf" という文字列が返ってきてしまいました・・・
またもや日本語処理に別の対応が必要になってしまいます・・・こまったもんだ・・・
調べると、ロケールの設定に依存しているため、というのがわかりまして。
setlocale(LC_ALL, 'ja_JP.UTF-8');
を実行してやると、上手くいくようになりました。

cakePHP での対応

pathinfo() やそのたぐいの関数を使うソースプログラムに、毎回 setlocale を記述するのは無駄を感じますね。
ましてや、プログラムを国際化対応しようとすると、あちこち変更しなければならなくなってしまいます。

cakePHP の config/app.php を見ると、次の記述があります。

'App' => [
    'encoding' => env('APP_ENCODING', 'UTF-8'),
    'defaultLocale' => env('APP_DEFAULT_LOCALE', 'ja_JP'),

これを利用して、config/bootstrap.php の 112 行目あたりに以下を追加しました。

setlocale(LC_ALL, Configure::read('App.defaultLocale') . '.' . Configure::read('App.encoding'));

まとめ

毎度のことながら、日本語対応は問題が多く発生しやすいですね。
国際化対応時に、上記対策でうまくいくのかどうかまでは試しておりません。あしからず。
今回も苦しめられましたが、なんとか事なきを得ました。

めでたしめでたし。

参考になったサイト
https://qiita.com/REAS07/items/3f86a0834d612edaecd6

2024年1月28日日曜日

Hyper-V に Ubuntu 22.04.03 をインストールしようとして・・・

なんども失敗したので、記録しとく。

いつものとおり、Ubuntuサイトから .iso ファイルをダウンロードして
いろいろと失敗したので。

cloud-init で停止してしまう

上段に[Install Complete!]がでたんで[Reboot]を選択したら、真っ黒画面になってしまって、一晩放置してもNGだった。
再度、インストールを試みてみると、ログで reached cloud-init のところで止まったまま。(これも一晩放置したけどダメ)
cloud-init を無効にする方法はネット上にあるけど、そもそもログインする前に死ぬので、どーしようもない
※このVM、Hyper-Vでは起動中のままになってしまって、削除することもできなかったよ。
Hyper-Vサービスを停止⇒PC再起動⇒VMファイルを削除⇒Hyper-Vサービス起動で削除できました。

そこで。ネットワークにつながない状態でインストールすればいいんだ!ということに気づいたわけです。 Hyper-V のネットワークアダプタを接続せずに新しい Ubuntu をインストールすることで、ようやくログイン画面にたどり着きました!

インストール後の注意点

Ubuntu の説明サイトを見ると、sudo コマンド経由の説明ばっかりで、めんどくさいですよね・・・
あちきは、もっぱら $ sudo su - を実行して root 権限に移動してから処理してます。

まだネットワークアダプタがない状態で、次をやっておきます。
cloud-init を無効化

  # touch /etc/cloud/cloud-init.disabled
  
これでネットワークつないで起動しても cloud-init で止まることはない(はず)

ついでに、起動高速化のため、あちこちに書いてある grub timeout を変更しておきます。

  # sudo gedit /etc/default/grub
  # GRUB_TIMEOUT=2
  # sudo update-grub
  

ネットワークを設定します。
# ip link でネットワークアダプタ名を取得します (ここでは、eth0)
で、ネットワーク設定の yaml ファイルを編集します。(IPアドレスは、ご自分の環境に合わせてくださいまし)

  # mv /etc/netplan/00-installer-config.yaml  /etc/netplan/00-installer-config.yaml.disable
  # vi /etc/netplan/01-installer-config.yaml
  network:
    version: 2
    renderer: networkd
    ethernets:
      eth0:
        dhcp4: false
        addresses: [192.168.0.90/24]
        routes:
          - to: default
            via: 192.168.0.1
        nameservers:
          addresses: [192.168.0.1]
  

ここで一度シャットダウン。Hyper-V の設定でネットワークアダプタを接続して起動します!
・・・真っ黒画面になってしまうかもしれません(実際、大汗でしたw
2分ほど待つと、boot シーケンスが動作し始めますので、我慢してください(笑)
ネットワークに繋がれば、TeraTerm でSSHログインできます。

真っ黒画面対策として、パッケージ関係のアップデートを行います。

  # apt update
  # apt dist-upgrade
  # apt autoremove
  

再起動してみましょう!

  # reboot
  
さくっと起動するようになりました。

blk_update_request: I/O error

Hyper-V コンソールを表示させると、しょっちゅう blk_update_request: I/O error が出力されます。
これは、フロッピーディスクがないってエラーのようです。 よそのサイトを参考に、以下の方法でエラーをなくすことができました。

  ▼ blacklist に登録
  # echo "blacklist floppy" >> /lib/modprobe.d/dist-blacklist.conf
  ▼ カーネルから floppy を削除
  # rmmod floppy
  ▼ dracut がなかったのでインストール
  # apt install dracut-core
  ▼initramfs の再構築をする
  # cd /boot/
  # dracut -f -v
  ▼再起動
  # reboot
  


次からは、失敗しないぞ!w
めでたしめでたし。

参考にしたサイト
https://x.momo86.net/article/154
https://qiita.com/n_mikuni/items/bf94289eaff93b82ac27

2022年8月18日木曜日

VM上のLinuxをVSCodeでPHPデバッグできなかった

ステップ実行できない!

もう何度も環境構築していて、手慣れているはずのVSCodeでPHPをデバッグする環境を用意していたら、なかなか動いてくれなかったのよ、これが。
簡単に環境を書きますと
ホスト:Windows PC+Visual Studio Code
リモート:VMWare + CentOS7.9
Apache:2.4.6
PHP:7.4.30 Zend Engine v3.4.0
Xdebug:3.1.5
ってな環境で、VM上のソースをデバッグできるようにようにしてます

SSHの設定とか、インストールの手順とかは書きません。悪しからずm(_ _"m)

やったこと(失敗の記録)

WEBを検索すると、以下のような記述が目立ちましたが、これはxdebugの古いバージョン用なので動きません

# vi /etc/php.ini

[xdebug]
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_host=192.168.xxx.xxx
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

ちなみに、192.168.xxx.xxxは、VM上のOSのIPアドレスです。

xdebug の新バージョンでの記述

以下のように記述するのが正しいと書いてありました。

# vi /etc/php.ini

[xdebug]
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.mode=debug
xdebug.client_host=192.168.xxx.xxx
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.discover_client_host=1

動いてくれません・・・

どうやって原因を突き止めればいいか、いろいろ悩みました

phpinfo()を使って、動きを確認してみました。

$ vi /public_html/phpinfo.php

<?php
phpinfo();


このファイルを作ってブラウザで表示し、xdebug の部分を見てみますと・・・

Step Debuggerの部分が disabled になってます。
xdebug.client_hostの部分が localhost になってます。
設定したはずの内容とは異なっています。なぜじゃぁぁぁぁ?
と悩むこと数時間。

xdebug.iniを修正する。

/etc/php.d/15-xdebug.ini ファイルを修正します。

# vi /etc/php.d/15-xdebug.ini

zend_extension=xdebug.so
xdebug.mode=debug
xdebug.client_host=192.168.xxx.xxx
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.discover_client_host=1

# service httpd restart

再度 phpinfo()を見てみましょう

Step Debuggerの部分が enabled になってます。
xdebug.client_hostの部分が 192.168.0.xxx と設定どおりになってくれてますね。

無事、VSCode上のブレークポイントで止まってくれるようになりました。(^_^)v
めでたしめでたし。

2018年12月30日日曜日

perl CGI HTML::Template で文字化け

Perl CGI での文字化け問題は何年も前に解決させたはずだったのですが(以前は Perl + Template の場合)
新しい CentOS (サーバに無料で入ってる Ver 6)の環境で、現在動作しているcgiを実行すると文字化けしてしまう現象に悩まされました。

ハマった手順を書いてみますね。

1)httpd.conf の変更
文字化けはこれでなおる!とネット上のあちこちに書いてあります。
# vi /etc/httpd/conf/httpd.conf

AddDefaultCharset off
または
#AddDefaultCharset off コメントアウト。


動作結果:NG
世界中でほとんど解決しているらしいのですが、うまくいきません。

2)php.ini の変更
# vi /etc/php.ini

;default_charset = "UTF-8"

default_charset = ""
に変更


動作結果:NG
そもそも php 使ってませんし。

ここでブラウザ側のレスポンスヘッダを確認してみますと utf-8 となっていました。
んー?なのに文字化け?理解できないぞ・・・

ちなみに、cgi のソースや HTML, CSS, JS, テンプレートファイルなど、すべてのファイルは UTF-8 で記述してます。(改行は LF)
なぜだろう、と、試験を実施することに。


3)簡単なHTMLを用意
[test.html]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>テストページ</title>
    </head>
    <body>
        UTF-8で記述されたページ
    </body>
</html>


動作結果:なんと、うまく表示されます。

4)cgi だとダメなのかな?
[test.cgi]

#!/usr/bin/perl --
print "Content-Type: text/html; charset=utf-8\n\n";
print "<html><body><div>\n";
print 'クオート文字';
print '<br>';
print "ダブルクオート文字";
print '<br>';
print "<div></body></html>\n";
exit;

クオートとダブルクオートで分けたのは、 perl の動作で文字化けしているのかどうかを確認するためです。

動作結果:なんと、うまく表示されます。

5)HTML::Template が怪しい。
どうやら使用している HTML::Template が怪しいのではないかとあたりを付けて検索したら情報がありました。
HTML::Template 2.98 で UTF問題が解決してる!というのです。
移行先のサーバーの HTML::Template は Ver,2.97 です。
ちなみにうまくいっていた旧サーバーの HTML::Template は Ver,2.94 でした。

Ver 2.98 のソースはここにありました。
https://github.com/mpeters/html-template

CPAN からのインストールしかやったことないので、git からどうやってインストールするのかわからずw
ダウンロードした HTML/Template.pm, HTML/Template/FAQ.pm をそのまま perl5 のファイルに上書きw

文字化けする cgi を動作させてみました。

動作結果:NG
ここまで、大量に時間を食ったにもかかわらず、うまくいかないとは・・・

6)binmode => 'utf8' を記述
既存 cgi の new HTML::Template 構文で、binmode => 'utf8' を追加する、との記述があったので
試してみました。

動作結果:NG
この記述は、上記リンクをたどる際に対応したパッチを当てたソースの場合に有効だったもので、動かないことは予想できていました。

7)utf8 => 1 を記述
HTML/Template のドキュメントを読み、new 構文の utf8 オプションがあることを発見。(旧サーバにはないオプションでした。)

既存 cgi の new HTML::Template 構文で、utf8 => 1 オプションを追加して実行してみました。

my $tmpl = HTML::Template->new(die_on_bad_params => 0, filename => $file, utf8 => 1);

動作結果:おお!!!!ようやく文字化けせずに表示されました!

しかしながら、問題があります。
既存プログラムの cgi ファイルは山のようにあります。
その全部にフラグを追加するのは困難ですよ。
デグレードなんか発生させちゃった日にゃ目も当てられません。
なんとかならないかな・・・

8)HTML::Template を編集。
perl5 の HTML/Template.pm を開いてみると、次のような部分なありました。

my %OPTIONS;
BEGIN {
    %OPTIONS = (
        debug                       => 0,
        ;
        utf8                        => 0,
        ;

ええい、こいつを1にしてしまえ!

        utf8                        => 1,

と変更した後で、既存の cgi に戻して動作

動作結果:OK

文字化けが解消されました!!!

モジュールの挙動が変わるなんて、ほんと困りものです。