HTTPプロキシ―に関しては、検索するとでてくるのですが、FTPプロキシ―の情報が少なくて、はまってしまった。備忘録です。 やりたかった事は、社内からFW越しに、FTP接続を行えるようする事です。 FWに穴を空けて「おしまい」というのもあるけど、いろいろ諸事情があり、プロキシ―サーバを立てて、経由する事になりました。 ためした事 ftpサーバを立てる squidサーバを立てる ssh トンネルを通す stunelを設定する。（考えただけで、実施せず） ftpproxyを設定する わかった事 は、ftpコマンドはNGでlftpで実現可能。バッチを考えるにはいいかも。 は、ftpもできるという情報が多かったけど、結局httpプロキシ―よりで、Windowsソフトでは利用できなかった。 は、ftpコマンドと同じ動きになってしまった。 基本は３．と同じだと思ったのでやらなかった。 nextftpの
NTP は、ネットワークを経由してコンピュータの時間を同期するためのプロトコル。通信は UDP プロトコルの 123 番どうしで行う。そして、NTP サーバデーモンの標準が ntpd だ。マシン自体の時計を合わせるだけなら、 NTP パッケージに含まれる ntpdate を使ってもいいが、オフィシャルドキュメントによると、 ntpdate はエラーハンドリングが「いい加減」なので、ntpd を -q オプションで使ったほうが良いようだ。 UNIX, Linux はサーバ運用を主眼として作られているので、時間が急に変わってしまっては問題が生じることが多い。そのため、ntpd は、マシンのクロックが違っていたからといって、いきなり何十分も遅らせたり進めたりはしない。連続性が失われないよう 「1 秒の長さ」 を実際よりも長くしたり短くしたりすることによって、徐々に補正していこうとする (一概に言
環境 RHEL5 ( ntp-4.2.2p1 ) RHEL6 ( ntp-4.2.4p8 ) NTPは結構微妙な修正を入れてくるのでバージョンが異なる場合は注意が必要。 manが当該バージョンの情報源としてはまず優先。 最近の変更 RHEL6ではRHEL5で /etc/init.d/ntpd のみで行っていたことを /etc/init.d/ntpdate と /etc/init.d/ntpd に分離している。 ntpd起動前のntpdate実行について分離している。ntpdを使うのであればntpdateも同時に有効にするべき(ntpdate実行を避けたい場合以外)。 設計 何もよりも先に 『参考』にあげた富士通の『Linuxユーザーズマニュアル RHEL6編』がNTPの説明として詳しい・わかりやすい。まずはこれを読む。 NTPサーバの階層設計 NTPを使う目的は『正しい時刻の維持』と『時刻
RetroBSD is a port of 2.11BSD Unix intended for embedded systems with fixed memory mapping. The current target is Microchip PIC32 microcontroller with 128 kbytes of RAM and 512 kbytes of Flash. PIC32 processor has MIPS M4K architecture, executable data memory and flexible RAM partitioning between user and kernel modes. Main features: Small resource requirements. RetroBSD requires only 128 kbytes o
入手方法 オフィシャルサイトからtar.gzを持って きても良いですが、SSL対応のためのソースのいくつかが含まれていないので、CVSからまとめて持っ てきてしまうのが楽でしょう。 % cvs -d :pserver:anonymous@cvs.sourceforge.jp:/cvsroot/stone login CVS password: (←空Enter) % cvs -d :pserver:anonymous@cvs.sourceforge.jp:/cvsroot/stone co stone コンパイル OS名を指定してmakeするだけです。SSLを利用する場合には、OS名に「-ssl」を付加します。なお、SSLを使う場合にはOpenSSLがインストールされている必要があります。Linuxディストリビューション によってはopenssl-develのような開発向けパッケージのイン
yebo blog: OpenSSHのベスト・セキュリティ・プラクティス
2009/07/27 OpenSSHのベスト・セキュリティ・プラクティス nixCraft に OpenSSH サーバのセキュリティ上のベストプラクティスが出ていたので、簡単にまとめてみる。 デフォルトのコンフィグファイルとSSHポート 説明前に前提となるコンフィグファイルの場所とSSHポートは次のとおりである。 /etc/ssh/sshd_config: サーバの設定ファイル /etc/ssh/ssh_config: クライアントの設定ファイル ~/.ssh/: ユーザの設定ファイルが入るディレクトリ ~/.ssh/autorized_keys: 公開鍵リスト /etc/nologin: root 以外でログインができない /etc/hosts.allow、/etc/hosts.deny: tcp-wrappersによるアクセスコントロール デフォルトポート: 22 #1 OpenSSH
案外身近な？ LDAP 古くから存在するのですが、使用する機会がないとなかなか概念を理解することができないプロトコル、そのひとつがLDAP（Lightweight Directory Access Protocol）ではないでしょうか？少なくとも数年前の筆者はそうでした。LDAPは「エルダップ」と発音します。 HTTPクライアント、HTTPサーバがあるよう、LDAPにもサーバ、クライアントという概念が存在します。LDAPサーバとは一言で言えばデータベースサーバなのですが、同じようにデータベースに分類されるPostgreSQLやMySQL、OracleなどのRDBMS（Relational Data Base Management System）と比較すると、一長一短があるため、管理対象のデータによって両者の使い分けを行うのが賢い選択です。 たとえばLDAPとはデータ追加や削除よりも検索を重
のざきさんの 「AT&TがEUC(Extended UNIX Code)をUNIXの文字符号化手法として使うようになったのって正確にはいつからなんですかね」 について。FreeBSD 4.6.2 からのわたしが解説しますよ。 結論からいえば 1985 年で、この年に System V Release 2*1 に対する拡張として、Japanese Application Environment がリリースされたようです (要公式リリース資料)。ただし、それが「EUC」という名前だったかについては今のところ不明。 その前段階として件の日本語UNIX システム諮問委員会では当然議論があったわけですが、その一員にAT&T UNIX Pacificがいる。ゆえに、1984年以前から実装は開始されていて、委員会へ開示されたタイミングである1984年がそのコードに残っているのではないか、と推測してみるわ
/etc/sudoers を LDAP で一元管理とかできないのかなぁ、と思っていたら、ちゃんと対応してた。 利用方法はわりと簡単で、上記リンクの README.LDAP （ソースに同じものが同梱されてる）を見ればすぐわかるけど、一応ここにやったことをメモ。ほとんど README からの抜粋です。 手元の Slackware に元から入っている sudo は LDAP 対応していないので、ここからダウンロード して以下の手順でインストール。 $ ./configure --with-ldap $ make $ sudo make install でもって /etc/ldap.conf に以下の記述を追加。（元々 LDAP は利用していて、基本的な設定はできているので、追加は一行だけ。） sudoers_base ou=SUDOers,o=southpark LDAP 側の設定はまずスキーマ
OpenLDAP 情報 OpenLDAP ソフトウェア 2.3 管理者ガイド OpenLDAP Software 2.3 Administrator's Guide の和訳です。 OpenLDAP 2.3 MAN ページ OpenLDAP 2.3.12 に付属の MAN ページの和訳です。 OpenLDAP 2.2 管理者ガイド OpenLDAP 2.2 Administrater's Guide の和訳です。 OpenLDAP 2.2 MAN ページ OpenLDAP 2.2.23 に付属の MAN ページの和訳です。 OpenLDAP 2.1 管理者ガイド OpenLDAP 2.1 Administrater's Guide の和訳です。 OpenLDAP 2.1 MAN ページ OpenLDAP 2.1.30 に付属の MAN ページの和訳です。 OpenLDAP 2.0 管理者ガイ
OpenSSLを利用した、自己認証局(CA)の構築と、サーバ証明書の作成手順とApache+mod_SSLでの設定方法についてもご紹介します。 Section.1では、通常のhttps通信を可能とするため、以下の手順を行います。 1.自己認証局(CA)の構築 2.サーバの証明書の作成 3.自己認証局によるサーバ証明書への署名 4.Apache+mod_sslの設定例 Section.2では、Section.1に加えてクライアント認証に利用する証明書の発行方法とApacheの設定例を示します。 1.クライアント認証用証明書の作成 2.Apache+mod_sslでの設定例 最初に、自己認証局(以下CA)の構築を行います。なお、CAの構築は/usr/local/CAに行います。 CAを作成するには、OpenSSL付属のCA.shを利用します。 (CA.shは、OpenSS
追記 以下の設定はうまく動いてくれません. 2010-09-15 - mooz deceives you に修正版が載せてあります. 元記事 Linux で OSX の open や Windows での cygstart, fiber に相当するものを実現するのは、デスクトップ環境を自由に選べたり選ばなかったり出来てしまうその特性から言って無理。 でも関連付けの概念があるデスクトップ環境やファイラを使っているのなら、 open に相当するコマンドが用意されていることがある。GNOME なら gnome-open といったように。 で、今日発見したのが xdg-open というコマンド。デスクトップ環境を判別した上で、 gnome-open など適切なコマンドを呼んだりするものとなっているみたい。 自分は今デスクトップ環境は使わずに awesome で済ませているので、関連付けはどうなるの
id:akio0911さんと話してた時に、こういう話ってニーズがあるんだって気づいたので、 簡単にまとめて見る。 心得としてはこんな感じ。 コマンドの実行時は履歴を確認 なるべくフルパス指定で サーバのトラブル時、リソースを確認する手段(CPU,メモリ,ポート,HDD) サーバで一番重要なのはログ 再起動手段、確認する手順、緊急対応に行った内容は記録に落としておく。 もちろんの事ですが、プロジェクト毎にルールが決まってればそれを優先して下さい。 一個ずつ解説していきます。 コマンドの実行時は履歴を確認 サーバの再起動とか、サーバのプログラムを確認する時、履歴を検索するのは非常に有効な手段です。 Ctrl + r のショートカットでrestartとかで検索し、ヒットしない場合は何度かCtrl + rを押して 遡れば見つかります。*1 再起動のコマンド等がドキュメントに書いてない場合等は特に重
This document is a collection of Unix/Linux/BSD commands and tasks which are useful for IT work or for advanced users. This is a practical guide with concise explanations, however the reader is supposed to know what s/he is doing. Unix Toolbox revision 14.5 The latest version of this document can be found at http://cb.vu/unixtoolbox.xhtml. Replace .xhtml on the link with .pdf for the PDF version a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
