久しぶりにWindowsでQtを触ってみようと思い、最新版のQt Creator（バージョン 10.0.0）をインストールしてみたのですが、以下のように最初からコンパイルエラーが出ており焦りました。
傾向として、以下のようにプロジェクトパスに日本語を含めると当該エラーが出るようです。
パスから日本語を除外したところ、コンパイルエラーが消えました。
環境は以下です。
ホストOSでIntel 12世代CPUを使用している環境において、Eコアだけを使用し、Pコアを使用しない事象が発生しました。バージョン16.2で事象を確認し、さらに最新版である17にアップグレードして再度検証しましたが、事象は解消しませんでした。
Eコアしか使用していないにも関わらず、なぜかホストOSのパフォーマンスも劣化（OS全体の引っ掛かりを感じる）するので、早急に改善を望みたい所です。
上記の画像の末尾4つが、Eコア、それ以外がPコアとなります。
（2023/04/30 追記）
タスクマネージャで「vmware-vmx.exe」の割り当てコアをPコアのみ（CPU0～15）にした所、パフォーマンスが改善されたような気がします。プロセスIDが変わるたびに再設定が必要になりますが、一旦これで回避ができるかと思っております。
当該ソフトには、ハードウェアの種類に「Trusted Platform Module」がリストにあるのですが、通常では選択できなかったので、選択できるようにするための手順を備忘として記載します。
パスワード入力して「暗号化」ボタンを押下します。このパスワードを失念すると、ゲストOS自体の設定変更もできなくなるので注意が必要です。
これで、「アクセス コントロール」が「暗号化されています」に変更されます。
この状態であれば、「Trusted Platform Module」が選択できるようになります。
その後、VMware起動時に当該ゲストOSを選択するとパスワードの入力を求められるようになるので、その場合は、入力したパスワードを入力してください。
これで、ゲストOSにWindows 11をインストールすることができます。
「php-fpm」サービスを再起動する必要があります。
systemctl restart php-fpm
FPMを使用している場合、Apacheを再起動しても「php.ini」の設定内容が反映されません。
「/etc/php.ini」にて「upload_max_filesize」を変更したのですが、Apacheの再起動で値が変わると思い込んでおり、ずっと以下のように値が変わらず、不思議に思っていました。
ちなみに、
php -r 'phpinfo();'
のように、コマンドラインから実行した際は「php-fpm」サービスを再起動しなくても設定変更がされます。
MediaWikiを1.37にアップグレードしたのでその手順を記載します。過去のアップグレード手順は、MediaWikiのアップグレード手順にあります。基本的には、公式サイトの手順を確認すれば十分かと思います。
MediaWikiのサポートPHPが、7.3以上に変更となったのと、CentOS 8がサポート切れになったので、環境を作成し直しました。dnfの向け先を変えれば、CentOSをそのまま使用できる方法もあるようですが、今回は採用しませんでした。
MySQLをバックアップします。
mysqldump -u <MYSQL_USER> -p <DB_NAME> > <DUMP_NAME>HTMLファイルをバックアップします。
cd /var/www
tar zcf <BACKUP_FILE_NAME> htmlApacheとMariaDBのインストール手順を記載します。PHPは7.4をインストールします。
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
sudo yum install MariaDB-server
yum install httpd httpd-tools httpd-devel
dnf module install php:7.4
dnf install php-mysqlnd php-gd php-pecl-zip php-intl
systemctl start mysqld
systemctl enable mysqld
systemctl start httpd
systemctl enable httpd1.27では不要だったのですが、1.37では、php-intlがインストールされていないとアップグレードに失敗するので、dnfに追加しています。
MariaDBのデータをリストアします。
mysqladmin -u root password <PASSWORD>
mysql -u root -pmysqlコマンドにて以下を実行します。
grant all privileges on *.* to <MYSQL_USER>@localhost identified by '<PASSWORD>' with grant option;
create database <DB_NAME> default character set utf8;「/etc/httpd/conf/httpd.conf」に以下を追加します。
Alias /w/index.php /var/www/html/w/index.php
Alias /wiki /var/www/html/w/index.php
Alias /index.php /var/www/html/w/index.phpDBダンプからインポートします。
mysql <DB_NAME> < <DUMP_NAME> -u <MYSQL_USER> -pMediaWikiをアップデートします。「/var/www/html」配下に移行前環境のバックアップファイルを展開している前提です。
wget https://releases.wikimedia.org/mediawiki/1.37/mediawiki-1.37.1.tar.gz
tar zxvf mediawiki-1.37.1.tar.gz -C /var/www/html/w/ --strip-components=1「/var/www/html/LocalSettings.php」に「$wgServer」の項目を追加します。本設定が無いとアップグレードに失敗します。
$wgServer = "http://<HOST_NAME>";MediaWikiのアップグレードを実施します。
cd /var/www/html/w/maintenance/
php update.php本内容でアップグレードは完了です。
件名の通り、各アプリで通信エラーが発生するようになりました。
以下は、IEの例です。
このページを表示できません
•Web アドレス https://go.microsoft.com が正しいか確かめてください
•Bing でこのサイトを検索
•ページを更新
詳細情報 詳細情報
DNS サーバーに問題がある可能性があります。
エラー コード: INET_E_RESOURCE_NOT_FOUND以下は、Evernoteの例です。（アクティビティログです）
20:01:58 [ERROR ] [17692] [22436] 0% Can't send HTTP request, error: INTERNET_CANNOT_CONNECT
20:01:58 [ERROR ] [17692] [22436] Bootstrap info: request to "www.evernote.com" failed, error: timeoutMicrosoft To Doはキャプチャはありませんが、同期に失敗します。再ログインしても事象は同じです。
これらの事象は、単一のPCでのみ起こり、別PCでは起こりませんでした。また、当該事象が起こるPCでも、ChromeやFireFoxは通常通りアクセスできました。
IEの設定をリセットすることにより、一連の事象が解消しました。具体的に何が改善したのかは、比較を取ってないので分かりません。本当にこの対処が解消と関係があるのかも定かではありません。たまたまかもしれません。こういうこともあるんだという程度のメモとなります。
ちなみに、「INET_E_RESOURCE_NOT_FOUND」を手掛かりに、IPv6を無効化するという記述のサイトも見かけましたが、それは効果がありませんでした。また、「ipconfig /flushdns」実施も効果がありませんでした。
※2021/09/25 補足
また同じような事象が発生しました。またリセットした所元に戻りました。何故このような事象になるのかは不明ですが…。
10年前位に、WordPressの導入手順としてページを作成しましたが、最新のバージョンに置き換える際、手順が色々と変更になったので改めて記載します。
CentOSにWordpressをインストールする手順は、探せば結構あるのですが、CentOS7.9にPHP7.4をインストールする際、そのままの内容ではうまくいかなかったりしたので、備忘として残した次第です。
今回、Apache、PHP、MariaDBは、yumでインストールします。
Apacheをインストールします。
yum install httpdPHPをインストールします。CentOS7.9の標準リポジトリでは、5.4がインストールされてしまうので、Wordpressが対応しているバージョンである7.4をインストールするため、EPELを使用します。
yum install epel-release
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum install --enablerepo=remi-php74 php
yum install --enablerepo=remi-php74 php-mysql
yum install --enablerepo=remi-php74 php-ldap
yum install --enablerepo=remi-php74 php-mbstringMariaDBのインストールも公式のリポジトリを使用します。「/etc/yum.repos.d/MariaDB.repo」ファイルを生成し、以下の内容を記載します。
# MariaDB 10.5 CentOS repository list - created 2021-04-27 08:44 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=0編集後、MariaDBをインストールします。
yum install MariaDB-server MariaDB-client以下はDB設定の参考例です。「mysql」コマンド実行後、以下のようにDB・ユーザ作成を行います。パスワードは適宜指定してください。
create database wordpress default character set utf8;
GRANT ALL ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;HTTP接続を許可するようにファイアウォール設定を変更します。
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reloadApache起動後、ブラウザアクセスをすれば、Wordpressの初期インストールが出来るようになります。これ以降の作業は一般的な流れになるので、ここまでの記載とします。
画像を記事に張り付けた際、以下のエラーメッセージが表示されました。
「ディレクトリ uploads/2020/09 を作成できません。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?」
該当ディレクトリのバーミッション・所有者は問題無かったのですが、上記エラーが表示されました。
原因は、Wordpressのファイルアップロードの設定でした。Wordpressアップグレード時、ApacheのDocumentRoot設定も変更したのですが、「設定 > メディア」の「ファイルアップロード > アップロードするファイルの保存場所」の設定が旧ディレクトリ（現状は存在しないパス）となっていた為でした。設定をデフォルトに戻したら正常動作となりました。
Docker Desktopインストール時に追加されたネットワークデバイス「vEthernet (Default Switch)」の「VMware Bridge Protocol」の設定をOFFにすれば、Workstationのブリッジ接続が再度使用できるようになりました。
たまに勝手に戻ることがあるみたいです。条件は不明…。
しばらくサイトを放置しておりましたが、インフラを少し更新しました。2011年から、さくらのVPNを使用していますが、VPNのバージョンを最新化しました。ほぼ同じコストで、SSDになり、ストレージ容量が2.5倍になりました。とは言え、体感速度はそこまで変わってないかな…。
しばらくは、こちら（Blog版）に投稿をしていこうかと思っています。理由としては、2点あります。
1点目は、下書き機能がMediaWikiに無いことです。一旦、記事を作成し、後日見直したうえで公開、という手順が取れないので不便でした。Draftという拡張機能があり、以前は使用していたのですが、MediaWikiのバージョンアップ時にエラーとなってしまい、面倒になり使用を止めてしまいました。
2点目は、MediaWikiで画像を含むページを作成する場合、別ページで画像を一つ一つ投稿して、手動でリンクを張らなくてはならないので、かなり手間となります。
また、Wikiに戻るかもしれませんが、その時はまたその時で…。何れにせよ、まずは内容を充実しないとですね。