どこにでもいるような普通の一般人が、たまに自分用メモを書いてる。

nazwa.pl の激安 VPS を契約してみた

日付:
タグ:

nazwa.pl というポーランドのホスティング業者があって、初回支払い分限定割引で目玉が飛び出るぐらい激安の VPS を出していたので思わず契約。

カタログスペックはこんな感じ。

  • 11.88 PLN / 年 (初年度のみの価格。このほか VAT やカード決済手数料が追加される)
  • メモリ 4GB
  • ディスク 25GB NVMe
  • 最大転送量 100GB / 日
  • 場所 ポーランド (ping rtt 270-300ms 前後)
  • KVM

サイトはポーランド語のみで作られている。読めないので Google 翻訳に頼りまくってなんとか契約した感じ。

契約時点でポーランドの通貨ズウォティ (PLN) は約31.15円。
VAT やらカード決済手数料やらが追加されるが、諸々含めてトータル500円程度。
PayPal に対応していないので、日本から利用するには事実上クレジットカードのみ。
普段使っているカードで支払うのにいささか不安を覚えてジャパンネット銀行のカードレス VISA デビットで支払ったところ、513円の引落だった。

513円でメモリ 4GB の KVM VPS が1年使えるって、これはかなりすごい話だ。
この価格は初回分のみで、通常価格は月 9.99 PLN。通常価格でも月500円未満なのでかなり安い。国内業者の8割引。

注意点としては、こんなところか。

  • ポーランド語なので翻訳に頼らなくてはならない
  • カートに入れた時点で有料オプションの DirectAdmin が選択された状態になっている (ので外す)

支払い完了から47時間強で開通。
身分証明書の提示を要求される事例もあるようだが、私の場合は要求されなかった。

さすがに経路が太平洋と大西洋を横断していくので ping rtt の数字が大きく、ssh は快適とはいえないが、動作自体は軽快。
vpsRus から Mastodon インスタンスを移転したら早くなった。

Debian stretch で Mastodon インスタンスを立て直した

日付:

前回、Ubuntu で Mastodon インスタンスを立てたのだが、さすがにメモリが 1GB では明らかに不足していて、Mastodon のバージョンアップに際して assets:precompile するだけで30分以上かかるという有様だった。
その上 CloudAtCost が長期間ダウンしたため、もう少しまともな環境で立て直すことに。

vpsRus の VPS で、カタログスペックはこんな感じ。

  • 2.5 USD / 月
  • CPU 2仮想コア
  • メモリ 2GB (vswap 2GB)
  • HDD 200GB
  • 月間転送量 1TB
  • 場所 イリノイ州シカゴ (ping rtt 200ms 前後)
  • OpenVZ

国内業者と比べると 1/4 以下のお値段。
シカゴにしては ping rtt がちょっと遅い。あとディスク I/O が結構遅い。たぶんユーザー詰め込んでるからだが、こんな値段でこれだけメモリ使えるなら我慢できる。


というわけで Mastodon を入れていく。
前回と比べるとプロダクションガイドも大幅に更新されており、それに従っていけば問題ない。
今回はプロダクションガイド #385に従うが、Nginx ではなく Apache を使う。
前回は rbenv を使わなかったが、今回は使う。


早い話:

  • redis-server と PostgreSQL がすんなりいかない。
  • redis-server は apt でのインストール時にエラーが出るので、/etc/systemd/system/redis.service の「ReadWriteDirectories=-/var/run/redis」から「/var」を削除して apt -f install。
  • PostgreSQL はデータベース template1 を encoding=’UTF8′ で作り直す。

node.js、yarn のリポジトリを追加、インストールしていく。プロダクションガイドは Ubuntu 16.04 ベースで書かれているが、Debian stretch も apt はプロダクションガイド通りに実行していい。

ただ、redis-server のインストールでエラーが出る。
これは /var/run が /run へのシンボリックリンクであることによるものらしく、/lib/systemd/system/redis-server.service の次の行を修正すればいい。

ReadWriteDirectories=-/var/run/redis

ReadWriteDirectories=-/run/redis
% sudo apt -f install

PostgreSQL の template1 が SQL_ASCII なのでうまくいかない。なので template1 を UTF8 で作り直す。

% sudo -u postgres psql
update pg_database set datistemplate=false where datname='template1';
drop database template1;
create database template1 with template='template0' encoding='UTF8';
update pg_database set datistemplate=true where datname='template1';
\q

バッドノウハウ!

Ubuntu 16.04 で Mastodon インスタンスを立ててみた

日付:

前回、Mastodon がメモリ食いらしいので代わりに GNU social インスタンスを立ててみたのだが、それでも一応 Mastodon も触ってみたくなったので CloudAtCost の Developer Cloud Pro 1 (メモリ 512MB、ストレージ 10GB) を2台持っているのを1台にまとめてインスタンスを立ててみることにした。

まとめるとこんな感じ:

  • なるべく APT で済ませる (基本方針)。
  • rbenv は使わない。Ubuntu 収録の Ruby 2.3.1 でいく。
  • なぜか bundle install 通らないのは Gemfile いじって無理矢理。

あ、Docker 使うのが普通みたいだけど使ってない。


基本方針は「なるべく APT で済ませる」だ。アップデートチャネルが多くなると面倒なので。
当初 Debian jessie で構築を進めていたが、Ruby 2.1 ではさすがに古くてどうにもならず、当然ながら ruby-build も古くて rbenv で Ruby 2.4.1 を入れることができず、rbenv 関係全部 git で入れる羽目になって基本方針とかけ離れてきたので中止。
なお CloudAtCost の Ubuntu イメージは 14.04 しかないので、まず最初に do-release-upgrade で 16.04 にした。

ベースは Mastodon のプロダクションガイドに従うが、APT で代替できるものは APT にする。
その際、PPA もどんどん使う。

以下、プロダクションガイドの記述順に沿って書いていく。


プロダクションガイドではユーザー mastodon、ホームディレクトリ /home/mastodon を使うことを前提としているのでユーザーを作っておく。違うものを使う場合は適宜読み替える。

Nginx 関係は後に回す。


まずは Node.js。プロダクションガイドの手順ではこうなっている。

sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev file git curl g++ libprotobuf-dev protobuf-compiler
curl -sL https://deb.nodesource.com/setup_6.x | sudo bash -
sudo apt-get install nodejs
sudo npm install -g yarn

1行目はそのままでいい。

2、3行目もそのまま。
Ubuntu 16.04 では Node.js 4.2.6 が収録されているが、後で必要になる browserify の導入には 4.6 以降が要求されるので、素直に 6.x を入れてしまう。

4行目は yarn の apt-line 追加に変更する。

wget -qO- https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt update
sudo apt install yarn

Redis と PostgreSQL はプロダクションガイドの通り。


次は Rbenv だが、Ubuntu 16.04 が Ruby 2.3.1 収録のところ、Mastodon は Ruby 2.4.1 を要求している。
しかし Gemfile を見ると 2.3.0 以上 2.5.0 未満となっているのでこのままいく。
つまり、rbenv は入れない!

sudo apt install ruby bundler

ユーザー mastodon に su しての作業は、git checkout まではプロダクションガイド通り。

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd live
git checkout $(git tag | tail -n 1)

ここからは違ってくる。
プロダクションガイドでは次のようになっている。

gem install bundler
bundle install –deployment –without development test
yarn install –pure-lockfile

bundler はさっき apt で入れたので1行目は除外。


.env.production は DB がローカルの場合、DB_HOST に localhost とか書くと ident 認証がコケるので、空にする必要がある。
こんな感じに。

REDIS_HOST=localhost
REDIS_PORT=6379
# REDIS_DB=0
DB_HOST=
DB_USER=mastodon
DB_NAME=mastodon
DB_PASS=
DB_PORT=5432

そしてセットアップ。

RAILS_ENV=production bundle exec rails db:setup

これはプロダクションガイド通りではあるが、Ruby のバージョンチェックで引っかかる。
/home/mastodon/live/Gemfile の4行目だ。

ruby ‘>= 2.3.0’, ‘< 2.5.0’

とあり、2.3.1 が入っているのだから問題ないはずなのだが。
PPA で 2.4.1 を入れた状態でも引っかかる有様だったので、行頭に # をねじ込みコメントアウトして無理矢理いく。

次に進む前に browserify を入れる。これだけは APT 管理できない。
node-browserify-lite では代用できなかった。

yarn add browserify

そして次に進む。

RAILS_ENV=production bundle exec rails assets:precompile

その次は systemd 周りの前に、Nginx と Let’s Encrypt を済ませる。


Nginx のインストール。

sudo apt install nginx

プロダクションガイド記載の設定は Nginx 全体のものではなくサイト設定なので、/etc/nginx/sites-available/mastodon とかファイルを作ってそこに書く。流用でいいが、一応ググって基本的な理解をしておいた方がいいとは思う。

流用の場合、基本的にすべて HTTPS でのアクセスになる。
HTTP は Let’s Encrypt のドメイン確認のみに使い、それ以外は HTTPS にリダイレクトされる。
SSL 関係の設定は Mozilla SSL Configuration Generator を参考に詰めることをおすすめする1
以下、流用ベースで書いていく。

なお HTTP の方にも

root /home/mastodon/live/public;

を書いておかないと certbot がコケる。

sites-available にあるだけではもちろん動かないので、sites-enabled にシンボリックリンクを張る。

sudo ln -s /etc/nginx/sites-available/mastodon /etc/nginx/sites-enabled/

certbot で Let’s Encrypt の証明書を導入しておく。

まずは certbot の導入から。

sudo add-apt-repository ppa:certbot/certbot
sudo apt update
sudo apt install certbot

/etc/ssl/certs/dhparam.pem も作っておく。

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

一時的に /etc/nginx/sites-available/mastodon の

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

は行頭 # でコメントアウトしておく。でないと今はまだ証明書も鍵もないので、Nginx がエラーを吐く。

sudo systemctl reload nginx
sudo certbot certonly --webroot -w /home/mastodon/live/public -d example.com -m admin@example.com

証明書ができたら、/etc/nginx/sites-available/mastodon の先ほどコメントアウトした部分を戻して nginx を reload。


プロダクションガイドの続きに戻って systemd 周り。
基本的にはプロダクションガイドの記述をそのままコピペでファイルを作っていけばいいのだが、rbenv を使っていないので /home/mastodon/.rbenv_shims/bundle はない。
/usr/bin/bundle を使う。

ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb

↑これをこうする↓。

ExecStart=/usr/bin/bundle exec puma -C config/puma.rb

crontab も同様に。


メモリ 1GB ではかなりカツカツという事前情報は正しく、ruby2.3 が4プロセスで合計 700MB 近く食っている。

以下はメモリ 128MB や 64MB といった極小 VPS でこそ役に立つものの 1GB 積んでると誤差レベルのメモリ節約にしかならないことだが、一応やっておく。

  • syslog は rsyslog から inetutils-syslogd に差し替える。
  • ssh サーバーは openssh-server から dropbear に差し替える。


  1. 流用そのままだと SSL Server Test スコア A- だが、少し詰めるだけで A+ になる。 ↩︎

シェルが使えない共有レンタルサーバーで GNU social インスタンスを立ててみた

日付:

忙しい人向けの結論:
Softaculous ついてる共有レンタルサーバーで Qvitter プラグイン入れるのが楽。
Softaculous でドメインの / に GNU social をインストールし、FTP 等で Qvitter を入れる。


先月あたり Mastodon が流行って、自分でもインスタンスを立ててみようと思っていたのだが、かなりメモリを食うようで躊躇していた。メモリ 1GB の VPS でも swap を使い始めるほどだと。
Mastodon は GNU social と互換性があると紹介されていたので、GNU social の方をチェックしてみると、ぶっちゃけ LAMP 環境で動く。
GNU social なら VPS ですらなく、いわゆる共有レンタルサーバーでもいけるのではないか? と思ったのが始まり。

しかし蓋を開けてみると GNU social もやはり設置先サーバーでシェルが使えることが前提になりそうだ。
インストールまでは問題ない。git がなくても master ブランチの zip をダウンロードして展開すればいい。
問題はバージョンアップで、1.1.x から 1.2.x へのアップグレード手順の説明 (UPGRADE) では script/upgrade.php をコマンドラインで実行せよとある。
試しにブラウザーからアクセスしたら、

This script must be run from the command line 

と表示されて動作しない。
将来のバージョンアップでも同じ手順を踏むと考えると、インストールまではシェルが使えなくても大丈夫だが、バージョンアップ時にシェルが必要になるわけだ。

つまり、シェルが使えない大多数の共有レンタルサーバーでは GNU social インスタンスを長期的に利用することは難しい、ということになる。


Softaculous という各種ウェブ・アプリケーション簡単インストーラーがあって、特に海外の cPanel 採用の共有レンタルサーバーではこれが導入されていることが多い。
これは何ができるかというと、コントロールパネルから選んで最低限の設定内容をフォームに入力していくだけで、対応アプリケーションをインストールできる。WordPress や Joomla やその他かなりの数のアプリケーションに対応している (対応リスト)。
バージョンアップがあった際の更新もコントロールパネル上で行うことができる。

そして Softaculous で簡単インストールできるものの中に、GNU social がある。
これなら将来のバージョンアップ時も Softaculous に更新させればシェルなしでいけるのではないか。


Softaculous で GNU social をインストールする際の注意点としては、インストール先ディレクトリが標準では「gnu」になっているのを空にしておくこと。
つまり https://example.com/gnu/ といったサブディレクトリで使うのではなく、https://example.com/ といったドメイン直下で使う。
https://gs.example.com/ といったサブドメインで使うのも良いかも知れない。

これは後述する Qvitter プラグインがドメイン直下へのインストールを要求するためだ。


GNU social で日本語表示を使うためには、locale/ja/LC_MESSAGES/statusnet.po や plugins/*/locale/ja/LC_MESSAGES/*.po を gettext のユーティリティ msgfmt で .mo に変換してアップロードする必要がある。
これはプログラミングをやる人以外には結構ハードルが高いと思われる。そもそも一般人の Windows PC に gettext なんか入っているわけがない。しかも変換すべきファイルが分散しているので make を使わないと面倒くさすぎるし、make もまた一般人の Windows PC には入っていない。

さらに別件だが GNU social の標準画面構成はなんとも古めかしくダサい。

Qvitter プラグインを使うことで、これらはそこそこ解決できる。
Qvitter は GNU social で Twitter のような画面構成を実現するプラグインで、多くの GNU social インスタンスで採用されている。
Quitter.se のように、画面にでかでかと「マイクロブロガー連合は~」と表示されていたら Qvitter 採用サイトだという認識でだいたい問題ないと思う。
Qvitter は初期状態で日本語表示してくれるし、その日本語表現を変更したくなったらテキストエディターで編集してアップロードするだけで済む (Qvitter の locale は gettext ではなく JSON であるため)。

早い話、Qvitter プラグインを使えば、画面構成のダサさも、とりあえずの日本語表示も OK ということ。


先に Softaculous で GNU social をインストールしておいてからの作業になる。
https://github.com/hannesmannerheim/qvitter で zip をダウンロードして展開 (PC に git が入っているなら https://git.gnu.io/h2p/Qvitter を見て git clone)。
zip の場合ディレクトリ名が qvitter-master になっているのを Qvitter にして、plugins/ にディレクトリごとアップロード。
有効化するには GNU social の config.php を編集して↓を追記。

addPlugin('Qvitter');

また Qvitter は Fancy URL を有効にしている必要がある。
Softaculous でインストールした直後の GNU social にアクセスすると https://example.com/index.php/main/all みたいな URL になっているはずだ (サイトタイプが Public の場合)。
これを https://example.com/main/all にするのが Fancy URL で、Softaculous でインストールした直後には有効になっていない。

というわけで config.php に↓を追記。

$config['site']['fancy'] = true;

Fancy URL は Apache の mod_rewrite で実現するので、htaccess.sample を参考に .htaccess を書く。
参考までに、うちのはこうなってる。

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule (.*) index.php?p=$1 [L,QSA]
</IfModule>

<FilesMatch "\.(ini)">
	Require all denied
</FilesMatch>

ユーザー登録時に表示される利用規約は plugins/Qvitter/doc/ 下で、これは日本語版がないので英語版が表示されるはずだ (plugins/Qvitter/doc/en/terms.html)。
英語版のファイルを参考に plugins/Qvitter/doc/ja/terms.html を書いてアップロードすれば、ちゃんと日本語版が表示される。文字コードは UTF-8。


これで普段使う部分はだいたい日本語表示になる。
細かいことを気にすると、たとえば登録時やフォロー時に送信されるメイルは英語のままだし、設定画面に入ってしまうとやはり英語だ。
でもそこを気にしてしまうと gettext を入れて .mo を作るクソ面倒な話の始まりだ。
このあたりが妥協ラインではなかろうか。

また、Softaculous でのインストール時点では Fancy URL が有効になっていないために、インストール時に作った管理ユーザーで投稿したものはタイムラインでのリンクがおかしくなる。
これの修正は phpMyAdmin で profile テーブルの id: 1 の profileurl を編集し、「index.php/」を削除すればいい。
よくわからなければ (Fancy URL を有効にした後で) 管理ユーザーとは別に普段使うユーザーを作り、そちらを使う。

国内では Softaculous 採用サービスはあまり見ない印象だが、mixhost が採用しているようだ。


なお、このインストール手法の場合、キュー処理デーモンを使わない運用になるので、大規模なインスタンスには向かない。

電力料金比較表を更新 (2017/04/02)

日付:

修正点:

  • ミツウロコでんき@niftyでんきを追加した。
  • 各事業者の料金表をもう一度見直して、こちらの間違いや事業者側の変更などで単価の不一致があったところは直した。
  • エルピオでんきは契約容量によって 120kWh までの単価に差があり、これまではその中で最も高い単価で計算していたが、契約容量ごとの単価で計算するようにした。
  • その事業者がその契約容量でのサービスを提供してないものに関して、従来は同事業者が提供するサービスの中で最も近い契約容量の料金を表示していたが、「提供なし」と表示するようにした。
  • イーレックス・スパーク・マーケティングはブランド名変更で erex になったので直した。
  • ENEOSでんきエルピオでんきerex は料金単価の記載があるページ URL が変更になっていたので、新しいものにリンクを変更した。

エルピオでんきは 30A までの料金も一応掲載しているが、新規申込は 40A 以上に限られている。
プロパンガスでエルピオ利用者である場合のみ「スタンダードライト30A」プランで 30A の新規申込が可能だが、従来の「スタンダードS」プラン 30A よりも基本料金、120kWh までの単価が高い。
表で掲載しているのは「スタンダードS」プランのもの。
新規申込ができないプランについては掲載し続けるかどうか悩ましい。
現エルピオでんき利用者が乗換先を検討するには有用だが、極端に使用量が少ない場合を除けばエルピオが最安値になる現状でその必要もないだろう。

(2017/04/16) やはり申し込めないプランは表示しないようにした。

ENEOS と my は合併で運営会社が同一になったが、料金体系は違う。
今後どうなるかは (自分が ENEOS 利用者であることもあって) 注目したい。

特別高圧・高圧を含む新電力シェアでは上位につけている丸紅新電力も料金計算用のテーブルは作ったが、実際計算してみると全面的に JXTG (ENEOS、my) より高いので比較表掲載は見送り。


(2017/04/07 追記)

今やってる価格.com のキャンペーンだと、@niftyでんきが12ヶ月間、月額1000円引きになるので、契約容量にもよるが 900kWh や 1000kWh 以下の利用量なら1年間の最安値はここになる。
キャンペーン期間、今月末まで。


(2017/05/08 追記)

価格.com のキャンペーン、同じ内容で5月もやっているようだ。

企業メアドへの送信でも特電法違反は成立するよ

日付:
タグ:

日本では特定電子メールの送信の適正化等に関する法律で spam (「迷惑メール」) 送信が禁じられているが、企業メイルアドレスへの送信は規制の対象外だと単純に考えているお花畑 spammer が散見されるので、それは間違いだと示しておきたい。
企業メイルアドレスが宛先であっても特電法違反は成立し得るのだ。

基本的には法第三条第一項第四号が「企業相手なら特定電子メールの送信が違法ではない」と考える根拠になっていると思う。

四  前三号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを公表している団体又は個人(個人にあっては、営業を営む者に限る。)

メイルアドレスを公開している団体は法第三条第一項第四号に該当し、「送信をしてはならない」相手ではない、というわけだ。
しかしここで終わりではない。「総務省令・内閣府令で定めるところにより」とあることを忘れてはならない。
それは特定電子メールの送信の適正化等に関する法律施行規則第三条で定められている。

(自己の電子メールアドレスの公表の方法)

第三条  法第三条第一項第四号の規定による自己の電子メールアドレスの公表の方法は、自己の電子メールアドレスをインターネットを利用して公衆が閲覧することができる状態に置く方法とする。ただし、自己の電子メールアドレスと併せて特定電子メールの送信をしないように求める旨の文言をインターネットを利用して公衆が閲覧することができる状態に置いたときは、この限りではない。

強調した部分が重要だ。

メイルアドレスを公開していても「特定電子メールお断り」等と付記しているものについては、規制対象になる

日本データ通信協会迷惑メール相談センター 情報提供ページにおいて、メイルアドレスのすぐそばに

このメールアドレスへの情報提供以外の特定電子メールの送信を拒否致します。

と記載されていることからも間違いない。


そういうわけで、株式会社ビーブレイクシステムズ1や、ゼロワンインターン2の株式会社そると3は反省するように。

また、株式会社ビーブレイクシステムズが使っている配信スタンドはシナジーマーケティング株式会社4だ。ここは2010年、私の個人メイルアドレスに YUCACEE (ゆかし) spam が届いていたとき、その配信スタンドだった。
シナジーマーケティング株式会社は、あれから6年以上経つ今も変わらず違法行為に荷担しているということになる。シナジーマーケティング株式会社は猛省せよ!


(2017/02/16 追記)

株式会社そるとについてはこんなプレスリリースを見つけた。
ゼロワンインターン spam は前にも酷似したものを見た記憶があったのだが、株式会社アイタンクジャパン5のキャリアバイト6のものだったと、ようやく記憶がつながった。
株式会社アイタンクジャパンは今月は送ってきていない (のと、たぶん先月送ってきていたと記憶しているが Gmail で spam フォルダーに入ったものを保存していなかった) ので今回「反省するように」のくだりで名前を出していなかった。
株式会社アイタンクジャパン側の主張としては、競業避止特約の不履行、顧客情報の持ち出しということになると思うが、前者はさておき、2社がまったく同じ特電法のお花畑解釈を採る可能性の低さ、2社からほぼ同内容の spam が届く可能性の低さ、2社の関係性を考慮すると、送信先リストの持ち出しは確かに強く疑われてよいと感じる。
株式会社そると側も刑事告訴やら民事訴訟やら始めたようで、個人的には spammer はつぶし合って共倒れしてくれるのが何よりだという認識。いやなら spam 送信という違法行為をやめることだ。

一応本記事では彼らが「不勉強で無知だから違法行為だと知らなかった。だからやってしまった」という逃げ道を残してやっているが、削除要求やら名誉毀損がどうのと抜かすようなら、ド腐れ spammer に見せるこれ以上甘い顔は持ち合わせていない。


(2017/04/16 追記)

株式会社ビーブレイクシステムズ1はあれからも複数回送信してきている。代表者 (私) の氏名まできっちり書いてきたこともあるので、要するに会社概要のページを見たということだ。そこにははっきりと spam お断りを示す文言を記載している。にも関わらず送信してくるということは、完全に遵法意識が欠落しているものと思われる。このような違法行為を繰り返す、いわば反社会的企業は、利用してはならない。

このほか楽天株式会社7からも月4900円出店プランの spam が届いている。「楽天市場 月額4,900円出店プランの最終案内」とあるが、架空請求詐欺のたぐい以外で初回から「最終」だのと言い出すメイルは実に珍しい。
当該プランについてググってみると、実際には決済サービス利用料とやらが別途乗って、どこが4900円だコラって固定費になるようだ。手数料率も Amazon.co.jp マーケットプレイス並、あるいはそれ以上に高い。
ところがそうした説明は、この spam の中には何一つ書かれていない。これは catch じゃないか。


(2017/05/11 追記)

株式会社ビーブレイクシステムズ1はエゴサーチしているようだ。これで送信を止めないようなら救いようがないな。
楽天株式会社7からは申込〆切の日付のみ差し替わったものがまた来ている。楽天は Salesforce8 を配信スタンドにしている。Salesforce も猛省せよ。


(2017/07/14 追記)

株式会社スクー9から spam が届くようになった。まったくコンプライアンスをどう考えてるんだろう。


(2017/09/15 追記)

クロスコ株式会社10から spam が届いている。会社の紹介動画作りませんかって、そんなものは何年も前から外人からさんざん spam 来るし、必要だと思えば自分の知ってるとこに頼むものだ。違法行為で飛び込み営業されて誰が買うかってんだ馬鹿め。配信スタンドは株式会社ラクス11。ここも spam 配信スタンドというわけか。
楽天株式会社は、6月に警告を送ってからは送信が行われなくなったようだ。

株式会社ビーブレイクシステムズ1からはエゴサーチ以後は届いていない。上場発表あたりのエゴサーチで Google のサジェストに「ビーブレイクシステムズ 迷惑メール」なんて出てたわけで、ようやく対応したと見える。
一方、株式会社スクー9は8月に警告を送った後も送信が続いている。こちらが明確なオプトアウトをした上でのことだから、完全な違法行為だ。株式会社スクーは違法に spam を送信し続ける反社会的企業であるから、利用すべきではない。


(2017/09/27 追記)

エッジコンサルティング株式会社12から spam が届いている。自慢の人工知能を spam 送信前に合法性の確認をしてくれるよう修正した方がいいだろうね。SpamCop でさっくり ISP に通報。でも abuse@gmo.jp はちゃんと対応してくれない印象なんだよなあ。


(2017/10/27 追記)

株式会社スクー9は8月に警告を送った際のメイルアドレスに spam を送ってきた。本当にどうしようもない犯罪企業だというほかない。


(2017/11/20 追記)

エッジコンサルティング株式会社12から spam が届いている。

この度は問合せフォーム自動入力により、
御社の新規開拓営業を圧倒的に高速化する、
営業支援システムのご紹介をさせていただきたく、
ご連絡させていただきました。

企業ウェブサイトによく設置されている問い合わせフォームに対する spam 送信システムだと!
エッジコンサルティング株式会社は完全なド腐れ spammer だ。


(2018/03/01 追記)

ド腐れ spammer エッジコンサルティング株式会社12からまた来た。
さくらインターネットと Amazon AWS に通報。


(2018/09/12 追記)

「シェア畑」の株式会社アグリメディア13から spam が届いている。

インターネットにある会社のご案内を拝見し、
農園近くの東京都大田区でいらっしゃいますので
農園のことを知っていただきたくメールを送らせていただきました。

会社が大田区にあることを踏まえての送信、つまり spam お断りと明記している会社概要のページを見た上での送信だ。遵法意識が欠落していると言わざるを得ない。
株式会社アグリメディアは猛省せよ。
配信スタンドは株式会社ラクス11。ここは1年前にも spam を配信してきている。頭越しにデータセンター宛チクってやった方がいいのかな。


(2018/10/10 追記)

「シェア畑」の株式会社アグリメディア13からまたしても spam が届いている。
違法行為を繰り返す株式会社アグリメディア、「シェア畑」は利用すべきではない。


(2018/11/09 追記)

「シェア畑」の株式会社アグリメディア13からまたしても spam が届いている。
違法行為を繰り返す株式会社アグリメディア、「シェア畑」は絶対に利用すべきではない。


(2019/01/30 追記)

コメント欄として Disqus をつけているのだが、本日このようなコメントが投稿された。

投稿者: unnka

本文:
脳みそ沸いてるのかい?

メイルアドレスは i***@salesmarketingfarm.biz だそうで。
spammer は確かに「脳みそ沸いてる」んだろうなと感じる。

「株式会社セールスマーケティングファーム」でググったら、サジェストに「迷惑メール」があるわ、検索結果3個目に spam で困ってる人のブログがあるわ、jpnumber でもぼろくそ叩かれてるわで笑った。



  1. bbreak.co.jp ↩︎ ↩︎ ↩︎ ↩︎

  2. 01intern.com ↩︎

  3. saltinc.jp、saltinc.co.jp ↩︎

  4. synergy-marketing.co.jp、synergy360.jp、crmstyle.com ↩︎

  5. i-tank.jp ↩︎

  6. careerbaito.com ↩︎

  7. rakuten.co.jp、rakuten.com ↩︎ ↩︎

  8. salesforce.com ↩︎

  9. schoo.jp ↩︎ ↩︎ ↩︎

  10. crossco.co.jp ↩︎

  11. rakus.co.jp、xbit.jp、hm-f.jp ↩︎ ↩︎

  12. edge-consulting.jp、geaine.jp ↩︎ ↩︎ ↩︎

  13. sharebatake.com、farmletter.biz ↩︎ ↩︎ ↩︎

HP t510 シンクライアント

日付:

  • HP t510
  • CPU : VIA Eden X2 U4200 1GHz (2コア)
  • GPU : VIA Chromotion HD 2.0
  • メモリ : DDR3 SO-DIMM 2GB
  • ストレージ : SATA DOM 16GB
  • OS : Windows Embedded Standard 7

外見は t5570 と区別がつかない。
中を見ると、ヒートシンク (筐体に熱を伝えるためと思われるシリコンシートが貼ってあるので、ヒートパイプ的な位置づけかも知れない) が大きいという点だけ異なる。
IDE と SATA が両方あるのも同じだし、その配置も同じ。
t5570 で t510 用の SOL-312-0 を流用できたのも当然と思える。
完全に t5570 の上位互換だ。

というわけで t5570 から SOL-312-0 をはずしてこちらに装着。t5570 は予備機と相成りました。

メモリは 4GB までのようで、8GB を装着しても 4GB として認識された。

初詣 (平成29年)

日付:
タグ:

今回は2年前同様、終電での移動。

参拝列の最後尾は鳥居をくぐった先で、この時間帯にしてはかなり短い方。
しかしながら列の進みは遅く、結局2年前とほぼ同じ時間になった。


すぐ近くにいた親子連れの子供が非常にやかましく辟易。
とにかく口から先に生まれたような感じの甲高い声でまくしたてるような、おそらく小学生中学年程度の男子。
おそらく親子4人で、父、母、当該クソガキ、その妹という構成。
どうも行列を見て並ぶのがいやになったようで、行列に対する不満を口にし、帰ろうと家族に主張しているのだが、その声がやたらでかく、そして内容が不謹慎に過ぎた。

曰く、

  • こんなに並ぶなら来るんじゃなかった
  • 小さいしょぼい神社でも初詣はできる、わざわざこんな混むところにする必要はない
  • どうせどこの神社でも変わらない
  • お参りしたっていいことなんか何もない
  • 去年もいいことなんか何もなかった
  • 神に会うのに並ぶ必要はない
  • どこの神でも同じ
  • 神は死んだ

これを参拝列の中で1時間も言い続ける有様。

親は一応なだめようとしているのだが、両親揃って息子にナメられているようで全然効果がない。
父親が子供の自尊心に訴えて静かにさせようと試み「子供だな−」と言うと、当該クソガキは「子供だよ!」と即答。
これには吹き出しかけた。

もちろん私を含めてその子供周囲の人々はチラ見、あるいはガン見。
70歳ぐらいの男性がものすごい形相で見ていたが、親すらそれに気づかない。
私は不謹慎コンテンツを好んで楽しむ方だが、さすがに同じネタをループで1時間じゃ飽きる。

子供の妹はそうやかましくもなく、参拝列が進むと無邪気に「進んだー」と言うのだが、それを聞いた当該クソガキは「うるさい!」と当たる。うるさいのはお前だよ。


おみくじは大吉。この神社で大吉以外を引いたのは、確か1回だけだったと思う。

まだ2時前とあって消え物屋台は閉めていない。
じゃがバター (ふかしてる方) と串焼きを食す。串焼きはもう500円では買えない時代か。
始発まで2年ぶりのeワールド府中店で3時間パック。


始発で帰宅したのだが、初日の出もまだ行けることに気づいて出発。
海芝浦は一昨年よりも人出が多く、柵沿いが確保できない。

今日の日の出は6:50だが、水平線からではなく扇島の工場街から上ってくるのを見ることになるので少し遅れる。
7:19の鶴見行きに乗り、そのまま帰宅、元日朝から寝る(笑)。

HP t5570 シンクライアント (2)

日付:

2016/05/14 の記事の続きにあたる。

前回の記事末尾で触れた、mSATA SSD を HP t510 の SATA ポートにマウントする変換基板「SOL312-0」を購入し、装着した。SSD は Transcend の 32GB (TS32GMSA370)。

t5570 + SOL312-0
元々は t510 用なのだが、ぴったり入っていて、まるで t5570 専用にあつらえたかのようだ。
この状態で WES2009 を導入し、問題なく動作している。
ヒートシンク上のシリコンシートが汚いのは見なかったことにして欲しい。

t5570 は元々 Disk on Module (DOM) がストレージとして搭載されているが、容量は 2GB しかない。
DOM でもう少し容量のあるものを買おうとすると、mSATA や2.5インチの SSD よりも割高になるし、数千円程度に収めようとすると AliExpress で中華 DOM を買うほか選択肢がない1
2.5インチ SSD は筐体内で固定できない。
そういうわけで、この変換基板はまさに「こういうの欲しかった」という言葉があたる。

t5570 本体に標準で装着されているスペーサー2では変換基板がぐらついて少し心許ないのだが、変換基板付属のスペーサーならガッチリ固定される。
mSATA SSD を変換基板に固定するネジも付属しており、かゆいところに手が届いた逸品だと思う。

製作者の方の記事はこちら



  1. 中華 DOM は大手 SSD メーカーと比べると品質に不安がある。 ↩︎

  2. ただし標準では SATA ではなく IDE の方に装着されている。 ↩︎

Wyse C10LE シンクライアント

日付:

電脳売王ヤフオクで出品していたものを落札。送料込での出品だが、赤字確定の121円で終了してしまった。

  • CPU : VIA C7 1GHz
  • メモリ : DDR2 SO-DIMM 512MB
  • ストレージ : IDE DOM 128MB
  • OS : Wyse Thin OS

HP t5570 同様に、ストレージは IDE 44ピンのオスメスが逆の Disk on Module (DOM) が装着されている。
しかし 128MB ではどうにもならない。

メモリは 2GB に換装し、DOM は t5570 付属の 2GB に換装した。


BIOS はパスワードがかかっているが、Wyse 製品共通の「Fireport」で入れる。
USB ブートも問題なくできる。

Debian を入れてみると、まったく普通に動く。あまりに普通すぎて拍子抜けしてしまった。
Thin OS には (いじれないので) 興味がなく、試してすらいない。

消費電力は 10W 程度。


拡張性はほぼない (USB はあるが)。

筐体の空き空間が少ないので、t5570 のように2.5インチ HDD/SSD を入れることは不可能。IDE-CF 変換アダプターぐらいはギリギリ入るかな?
筐体の上面全体から上に放熱する構造なので、あまり障害物を増やすのも気が引ける。


(2019 追記)

やじうまPC Watch ジャンクな500円シンクライアントで遊ぶ

1.8インチ HDD を内蔵している。 コの字型ヒートシンクの隙間に HDD がある配置なので、熱が怖いなあ。