未分類

AFNetworking.h not Foundのエラーが出て実機で起動できないときの対処法

CocoaPodsで入れたAFNetworking.hのエラーの対処法

#import “AFNetworking.h”で呼び出すと実機テストでAFNetworking.h not Foundというエラーが出て起動できないことがあるのですが、特殊な方法で修正できることがわかりました。

すごい単純なのですが、Cleanをした後「Generic IOS Device」を選択してビルドし実機でRunすると直ります。

毎回Archiveすると治るので変だなぁと思っていたのですが、なんとも。

原因は全くわかりません。

他のAFNetworkingを利用しているプロジェクトではエラーも出ませんし。

とりあえず動くので、原因がわかり次第また追記したいと思います。

 

AWSで再起動後、SSHが繋がらなくなった場合の対処法。SELinuxが原因でした。


開発サーバーの再起動テストを行ったところ、SSHが繋がらなくなった。

原因はSSHのポートを変えて、SELinuxのせいでsshdが起動せずというわけで単純なものだったが、切り分けには数時間を要した。

 

まず、こういう場合にはボリュームは生きているはずなので、別のサーバーへボリュームをアタッチすることを考え、別の適当なサーバを立ち上げアタッチしてみた。

すると、そもそもどのボリュームをマウントしていいかわからない問題が発生した。

AWSだとボリュームあとアタッチすると/dev/xvdk・/dev/xvdk1・/dev/xvdk2みたいに3個増え、どれをマウントすればいいの?っていう。

で、ここでAWSサポートに連絡して、一応lsblkっていうコマンドで確認すればいいですよーっていう連絡をもらった。

AWSサポート、マジ神。

 

で、マウントしたはいいが、どう問題をきりわけたらいいのかと悩み藁をもすがる気持ちで/var/log/messagesを見る。

すると、

 

Jul 19 23:00:31 localhost systemd: Stopping OpenSSH server daemon…

Jul 19 23:00:31 localhost systemd: Started OpenSSH Server Key Generation.

Jul 19 23:00:31 localhost systemd: Started OpenSSH server daemon.

Jul 19 23:00:31 localhost systemd: Starting OpenSSH server daemon…

Jul 19 23:00:31 localhost systemd: sshd.service: main process exited, code=exited, status=255/n/a

Jul 19 23:00:31 localhost systemd: Unit sshd.service entered failed state.

Jul 19 23:00:31 localhost systemd: sshd.service failed.

 

sshが繋がらないのはネットワーク系ではなく、特に問題なのは太字の箇所。

なんでsshdが繋がらないのか・・・・と思ってググったところ、selinuxという文字が。

sshのポート番号をデフォルトにするとselinux発動、みたいな。

こちらも藁をもすがる気持ちでselinuxの設定を見てみた。

 

コマンドは、sudo vi /etc/selinux/config。

そしたらenforcingになっていたので、disbaledに変更。

AWSのコンソールに戻ってボリュームのデタッチ&元のサーバにアタッチして再起動。

 

そしたら、、、、

 

 

無事SSHつながった。

ビール飲んだ。

300円くらいするやつ。

 

この記事を見て誰かもビール飲める状況になれば幸い。

AWSにベンダロックインされてしまっているのが心配


DynamoDBなんか使うともう他のサービスに移行できない、ベンダーロックイン状態になる。

何が悪いかというと、他のサーバーに移したりすることが困難になること。

他に魅力的なサービスができたとしても移行できない心配とかは無視してもいい。MongoDB/MySQLを利用しても移行のコストは同じだけかかるし。

 

あとはAWSがなくなったらどうすんだ?っていうリスクも。

後者は自社の方が無くなる可能性が高いのでほぼ心配はない。

 

唯一あり得るのは、不当な値上げ。

ただ、これはリザーブドキャパシティをあらかじめ買っておけばある程度は防げる。

 

一応、心配はしたものの大丈夫なような気がしてきた。

何か他に心配すべきことがあれば知りたい。

Amazon API Gateway / DynamoDB / Lambdaで数百万imp / 日さばいてみた

サービスの耐久性能を1日数百万impから1日数千万impに上げたいと考え、AWSのLambda / API Gateway / DynamoDBの構成を擬似的にテストしてみた。

たしかに、小学生でもスケールアウトができるDynamoDBとLambdaは最高で、価格も超安かった。

でも、1日数百万impだとAPIGatewayの金額がちょっと面倒臭い値段になる。

Dynamo / Lambdaは数千円 / 月で済みそうだったが、API Gatewayは数万円 / 月。

うーん、数万円はちょっともったいないので実装の時間ができるまで一時停止。

でも、導入は確実にしなければならないので、次再開したらリリースの予定。

こういう実験は常日頃からしておくと、値段感もわかるし新しい技術の勉強にもなっていい感じだと思う。

linuxのコマンドをバックグラウンド実行の進捗状況を確かめるコツ

バックグラウンドで実行するとき、なんで >  rsync.logみたいに書き出すの?

どこまで進んでいるかどうか、後でtail -f で確認するために標準出力ではなく、ファイルに書き出すようにしています。

※本ページは下記の記事を読みやすくするために抜粋しています。併せてご覧頂ければ幸いです。

パスワードが必要なrsyncやscpを長時間バックグラウンドで走らせたい

パスワードが必要なrsyncやscpを長時間バックグラウンドで走らせたい

パスワードを求められてもバックグラウンドでscpやrsyncを走らせるには?

  1. ログファイルに書き出しながら実行
    • rsync  REMOTESERVER:/home/shisuh/tmp/ ./tmp > rsync.log
  2. Ctrl+z で一旦停止
  3. jobs -l で番号確認
  4. bgコマンドでバックグラウンドへ
    • bg 1
  5. disownコマンドでログアウトしても大丈夫にする
    • disown %1

&コマンドではダメな場合はどんな場合?

パスワードが求められない場合には、&だけでなんとかなり、パスワードが求められる場合には、今回冒頭に書いたような方法で実行するのがベストだと思います。

バックグラウンドで実行する例は?

以下のように&マークを付けるとバックグラウンドで実行できます。

rsync  REMOTESERVER:/home/shisuh/tmp/ ./tmp > rsync.log &

パスワードの入力が必要なご注意下さいませ。

バックグラウンドで実行するとき、なんで >  rsync.logみたいに書き出すの?

どこまで進んでいるかどうか、後でtail -f で確認するために標準出力ではなく、ファイルに書き出すようにしています。

参考URL

http://d.hatena.ne.jp/shima111/20110714/p1

npmコマンド実行時にbad interpreter:が出力されたときの対処法

npmコマンド実行時で以下のようなエラーが出た場合の対処法

npm ls を実行したときに、bad interpreter: *** /nodeなエラーが出たときの解決法を以下に記します。

解決方法は再インストール・・・と単純

curl https://npmjs.org/install.sh | sh

という一行で解決しました。

理由の推測

npmのインストール時に以下のようなメッセージが出ていたこと、僕の場合はNode.jsのディレクトリを最初にインストールしたディレクトリから変えたため起こりました。なので、おそらくインストール時のNodeのパスを覚えておいて、それを使い回すような設定に成っているんだと思います。

 

参考URL

同じbad interpreterのエラーが出ていた方

僕が採用したくなる変態エンジニアの生態 その3

変態エンジニアシリーズとは

僕の少ない採用経験、およびエンジニア経験から採用したいなと思った人や、仕事をまたしたいと思った人の特徴を上げていくシリーズです。

今回は、アプリケーションエンジニアではなく、インフラ系の保守・運用エンジニアについてのお話をさせて頂きます。

保守に強い変態エンジニア

エンジニアというとプログラミングでソフト製作、という一般的なイメージがあるかと思いますが、もう一つ重要な任務を忘れてはいけません。サーバが常に動いているのは、保守・運用を行うエンジニアの活躍があってこそです。

保守ができる人がいるプロジェクトといないプロジェクトでは、金銭面でも納品面でも安心感が違います。

保守・運用の経験から開発中からでも準備をすることができる

保守の人は全体を見て原因の切り分けをする必要があるため、視野が広いです。
なぜ視野が広いのかと思ったら、アプリケーション・サーバ・ネットワークとレイヤーごとにスパっと割り切って考えていることが一番の原因だと思います。

そのため、開発時に考慮漏れが少なくなる事は間違いありません。

保守・運用フェーズには言うまでもなく役に立つ

経験の浅いアプリケーションエンジニアは問題があった場合、アプリケーションの調査から入る人が多いように思えます。
しかし、実は外部連携しているサービスが落ちていたり、レンタルサーバが保守中だったりすることがあります。
そのような場合にでも、前述のように視野が広いため順序を間違えずに最短で調査をすることができます。

そんな場合は少ないよ、とおっしゃる方にもう1事例。

営業面でも大活躍

お客様やユーザがトラブル時には「システムに問題があった場合は全てソフト作った人の責任」と考えてしまうようです。
そして、経験が浅い営業だったり、または小さい企業で働いていると「それもそうだよな」なんて納得してしまうこともあります。

誰もあなたのことを狙っていないのに、自ら包囲網を敷いている人をよく見かけます。
保守エンジニアはそういう人達のことを「本当にしょうがない人達」と陰では思っているのかもしれません。
(実際、僕もそう思われていました)

オープンソースを利用している場合、サーバ屋、オープンソースコミュニティなど、実は最短手順というのは構築した会社に問い合わせることではありません。

こういう場合はサーバ屋、ああいう場合には我々の出番というのがきっちり線引きされていれば、お客様もわざわざアプリ担当に声をかけてくる理由はないんです。
その場合には、お客様に各レイヤーごとの役割を教えて上げることで、責任分解ができます。

保守エンジニアは先ほども申し上げた通り、全てのレイヤーを見ているのできっちり責任分解が頭の中にあります。
ネットワーク、ハードウェア、ミドルウェア・・・・というレイヤー図。

僕はとあるエンジニアにこの事を教えてもらい、目から鱗が落ちる思いでした。
視野が広い、保守のエンジニアならではの視点だなと思いました。

おまけ:発注者側が安心して安く発注するには

もし、発注する立場から見た場合、最も低予算かつ迅速な対応をするには、責任分解を自社で負う事をオススメします。
見えないリスクを減らしてあげる事で、下請け見積もりを下げる交渉材料ができる事も覚えておいたほうがいいでしょう。