Lycolog

ここ1年くらいのことだと思うが、さくらのレンタルサーバーを利用しているサイトで以下のようなエラーが出てくることが目立つようになった。

「以下HTTPのURLにアクセスすることで～」と書かれているが、恐らく踏んでも意味がない。何故なら勝手にhttpsとして解釈されるためだ。少なくともChromeやEdgeはそのような挙動をする。

この場合ブラウザのURL欄をhttpsからhttpに直接書き換えてやればアクセスできるのだが、そんなことをする人間はオタクを除き、まずいないだろう。

またそこまでしてもアクセスできない場合がある。それはフレームサイトの場合だ。<frameset>が使われているサイトの場合、モバイルブラウザで開けない可能性がある。少なくともAndroid Edgeでは開けないし、このツイートに関する一連の流れを見ていて、恐らく一般的にはそうなのではないか？と感じたからだ。

HTMLの後方互換性は長らく謳われていたと記憶しているが、そろそろIEの存在のように、葬り去られる時が近づいているのかもしれない。そもそもhttpsでないサイトは危険で、フィッシング詐欺などの被害にあったり、個人情報の漏洩に繋がるとされており、こういったサイトは認められない風潮があるので、ある程度は仕方がないのかもしれない。

ドメインをValue-Domainで管理していてネームサーバーもValue-Domainを利用している場合に、さくらのレンタルサーバーで利用しているメールドメインにSPF, DKIM, DMARCのレコードを設定する方法。

手順

以下はexample.comというドメインを利用していると仮定して書いている。またGmailに弾かれない様にするための最低限の設定であるため、なりすまし防止などの高度な設定をする場合は設定画面の項目をよく確認して対応してほしい。

1. さくらのレンタルサーバーのコントロールパネルにログイン＞ドメイン/SSL＞ドメイン/SSL
   

   

2. 該当ドメインの設定＞DKIM設定
   

   

3. DMARCレコードにチェック＞設定する
   

   

4. 該当ドメインの設定＞DNSレコード
   

   

5. レコード情報を確認し、ValueDomainの設定画面に転記する
   

   

6. Value-DomainDNS設定に、上記内容を以下の要領で転記する

   txt @ v=spf1 a:www9999.sakura.ne.jp mx ~all
   txt _dmarc v=DMARC1; p=none; aspf=r; adkim=r
   txt rs20240201._domainkey v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn6x1qUbFlFnEiIGYlJUCQdPszZhmTIJz7HRNNqRLiS2XcfhgMKGf1q04tzz/SBLOX8iksVvfiKzQRRKi8GitcOZ46FU6HXinb+Q4Uih9rHfZi3LHMm6a/Y5zPg5tikkDPW5068o9Vy47CbML6WHd8DcR6wfLokS8JcsImkdPj4U2begce+eUdESkJbUWD3w 8pHCq2RAGlF7POF4gYCyZszEgD7ZpK69JS0FtxyCSP5dUVk5beCZhArIXbosh9hwXwU0tEt0VlO4VQokYgYadVA6DKfv+LuV66AwjC5r36P4fwYtLpd989p5D28+OWBV02bPaUCRvAWTlWB43sNQERQIDAQAB
   

7. GMailに送信し、SPF, DKIM, DMARCがPASSになっていればOK
   

   

注意点

DKIMレコードはさくらのコンパネ上では改行されているが半角スペースで繋げて書く。またダブルクォートは外して書く

サーバーサイドでMarkedを使いたかったので。Node.js 20系はC++やclangのバージョンが古くエラーになると思われるので18系にした

前提

• さくらのレンタルサーバースタンダードプラン
• zshを利用している

手順

所要時間はさくらのレンタルサーバースタンダードプランで2時間丁度くらい

1. nodebrewを落としてくる

wget git.io/nodebrew

1. .zshrcにパスを通す

   1. PATH=${HOME}/.nodebrew/current/bin:${PATH}

2. コンパイルして使えるようにする

perl nodebrew setup
## バージョン確認
# nodebrew ls-remote
## プロセスが殺されるのを防ぐためにniceで優先度を下げている
## コンパイルには2h程かかる
nice -n 20 nodebrew compile v18.19.0
nodebrew use v18.19.0

試したけどうまくいかなかったやつ

nvm

niceが効かないのでプロセスキルされて終わる

フルスクラッチコンパイル

OpenSSL周りに何か問題があるらしくコンパイルがこける。バージョンが合ってないのかも

# OpenSSL
wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz
tar -zxvf openssl-1.1.1w.tar.gz
cd openssl-1.1.1w
./config --prefix=/home/$USERNAME/openssl --openssldir=/home/$USERNAME/local/openssl
make
make install

# Node.js
wget https://nodejs.org/dist/v18.9.1/node-v18.9.1.tar.gz
tar -zxvf node-v18.9.1.tar.gz
cd node-v18.9.1
./configure --shared-openssl --shared-openssl-includes=/home/$USERNAME/openssl/include/
export LD_LIBRARY_PATH=/home/$USERNAME/openssl/lib
make install DESTDIR=/home/$USERNAME/local PREFIX=

所感

Node.jsなので負荷が心配だったが、Markedでブログ記事をMarkdownからHTMLに落とす程度なら問題なく動いて安心した。

ここ数年、誰かと話をしたりしているときに話のネタ元を探すのに苦労することが増えた。恐らく昔は根拠なく話していたことが、今は根拠を求められたり、必要になるケースが増えたからだと思う。相手を納得させる話には説得力が必要で、それには根拠があると捗るためだ。

例えば、「以前ほげほげで見た話なのですが～」と切り出したときに「ほげほげ」がどこだったかというところだ。私は大抵の情報をWebから得ているので話の元には大抵URLがあるのだが、これを失念していると根拠が出せないうえに記憶が壊れているケースもあり、誤った情報を話してしまうことがある。しかしこんなのを普通にブックマークしていても探すのが大変だし、ブックマークもすごいことになってしまう。そこで、記憶のインデックスとしてソーシャルブックマークを使うのはどうかと、ふと思いついたのだ。

最初はdeliciousを使おうと考えたのだが、これはサービスを終了していた。Diggも頭の中を過ぎ去ったが、今ひとつパッとしなかった。そこで行き着いたのがはてなブックマークだ。

ここはインターネット黎明期のころにインターネットをしていた人たちにとってお馴染みのサービスだろう。私も黎明期にはよく使っていたが、その時は特に理由もなく、流行で楽しいからという理由だったと思う。

しかしある時を境に私は利用をやめてしまった。理由はホッテントリの存在である。控えめに言わずとも荒れているし、スパムも多い。これは別に最近に始まったことではなく、以前からこうだった。最近はより酷くなってきている気さえする。しかし別にホッテントリを見ずに純粋に自分だけのブックマークとして使えばいいのではないか？そういう部分に気づいたのである。他者を気にせずに使う分にはストレスがない。そう思い使い始めることにした。

取り合えず今は思い出したときに、過去に見つけた有益情報をブックマークしていっているところだ。きっといつか情報を引き出す時に役に立ってくれることだろう。そう思い今は登録するフェーズにいる。勿論、過去だけではなく、現在見つけた情報についても関心があるものはブックマークしていっているが、どちらかというと過去を引き出したい側面の方が今は強い。

現在私のブックマークは技術的なものや地域の話題のようなものが多い。特に技術の話については引き出しから出したときに中身が抜け落ちていることが多々あるので、これをインデックスの一つにして、すぐに引き出せるようにしておきたい。

ここからは余談だが、実は久々にはてブを使うにあたり、IDの再登録をした。これは過去に、はてなというサービスに失望してこのIDを消してしまったところに所以する。

悲しいことはIDがアッパーケースで登録できなかったところだ。今のIDはlycoliaであって、Lycoliaではない。過去のIDが再び取れたら最高だったのだが、まぁ昨今のサービスだとなかなかないだろう。大昔はよくあったものだが。

まぁ、世の中には小文字しか使えないサービスもあるので、それと同じだと思えばいい。正直大文字が使えるサービスでも小文字で登録しまっている例があるので、深く気にするだけ負けだ。中には過去にアカウントを作ったが消してしまったので、既に使えないサービスもいくつかある。今後はIDを不用意に消さないようにしていきたいものだ。（とはいえIDが多いと管理コストもかかるので難しいところではあるが）

Athenaクエリ周りのメモ。

Athena前提知識

Amazon Athena とはによると、次のようにあるが、癖があることは覚えていた方が良い。

Amazon Athena は、標準的な SQL を使用して Amazon Simple Storage Service (Amazon S3) 内のデータを直接分析することを容易にするインタラクティブなクエリサービスです。

関数についてはAmazon Athena の関数を見るとよいのだが、Prestoのサイトを見たほうが多分早い。

UTCのISO日付書式文字列をJSTロケールのtimestampに変換する

SELECT
  date_parse('2020-01-05T23:21:00.53Z', '%Y-%m-%dT%H:%i:%s.%fZ') AT TIME ZONE 'Asia/Tokyo' AS jst

timestampをdate型に変換する

SELECT
    CAST(TBL.TSTMP AS date)
FROM (
    SELECT timestamp '2020-11-20 01:00:00' AS TSTMP
) TBL

TO_DATEはtimestampを受け付けないので役に立たない。TO_CHARはドキュメント上扱えるように見えるがフォーマット文字でエラーになる。

以下の様にしてもサポート外の数値型が渡る様で上手くいかない

TO_CHAR(year(TBL.TSTMP)) || '-' || TO_CHAR(month(TBL.TSTMP)) || '-' || TO_CHAR(day_of_month(TBL.TSTMP))

date型をWHEREで比較

date YYYY-MM-DDとして、型を明示しないと上手くいかない

SELECT
  *
FROM
  TBL
WHERE
  TBL.createAt = date '2023-11-22'