iPhone用 Google blogger公式アプリケーション、その名もズバリ blogger から投稿テスト。
----
フライトモードにしてオフラインで追記してみた。
続けて新規作成しようとしたが、未アップロード記事の編集画面になる。
オフラインで記事の書き溜めはできないみたいです。
オンラインでサーバーにdraft保存すれば書き溜め可能のようです。
つたない検証なので間違っていたらごめんなさい。
----
再度試してみたら、フライトモードでも複数記事を書き溜めできました。
BlogPressのアドバンテージはタグの選択入力くらいしかない気がしてきました。しかもBlogPressは日本語入力カラムが編集画面にかぶってカーソルが見えなくなるし...
2011/09/21
2011/09/18
ゲストマシンをディスクイメージとしてバックアップする
そもそもゲストマシンはディスクイメージとして存在しているので、ホストマシンがそのファイルをコピーするだけで良いのですが、スパースファイルを再構成することで一度大きくなってしまったディスクイメージを小さくしましょう、という意図があります。
(SSDが潤沢にあればこんなことしなくて良いのに!)
また、ホストマシン側は 4GBのSSDしか使用できない環境なので、今回はゲストマシン側だけで何とかします。
(SSDが潤沢にあればこんなことしなくて良いのに!!)
なお、このblogは例によってメモ for 未来の私 です。
ゲストマシン環境
ディスクマウント状態はこんな感じ
/dev/xvda3 /dataは SDHCです。
バックアップ対象は /(/dev/xvda1) だけです。
バックアップ保存先は /data(/dev/xvda3) です。
ホストマシン側から見ると、
/dev/xvda1 と /dev/xvda2 は EeePC 4G-X 上のSSDに保存されている ディスクイメージファイル(スパースファイル)です。
/dev/xvda3 は外付けSDHC(/dev/sdc1)です。
ホストマシン側でマウントしているデバイスはゲストマシンでマウントできないため、ホストマシンは /dev/sdc1はマウントしていません。
仮想マシン起動用のcfgはこんな感じ(抜粋)
バックアップ手順
1. ディスクイメージ作成
2GBのスパースファイルを作成します。
作成先は /data/tmp/disk.img です。
2. ファイルシステム作成
作成したディスクイメージに ext3ファイルシステムを構築します。
対話的に y/n を聞かれることがあるので、自動的に y を答えるようにします。
3. 作成した空ディスクをマウント
ループバックデバイスとして作成したディスクを /mnt/tmp にマウントします。
4. コピー
rsyncを使用して、/(ファイルすべて) を /mnt/tmp にコピーします。
ただし、SDHCである /data/ と マウントしている /mnt/tmp/ は除外します。
90秒スリープしているのはバッファの内容を書きこむのを待っているため。sleepしなくても良いのですが、なんとなく。
5. アンマウント
マウントを解除します。
6. GNU tarでアーカイブ
gzip や bzip2 では sparseとしての扱いが出来ずに、今回であれば 2GBのファイルとして扱ってしまいますが、sparseファイルが扱える GNU tar (Sオプション)を使い、/data/tmp/disk.img から /data/Dropbox/backup/disk.img.tgz を作成します。
/data/Dropbox は Dropbox同期ディレクトリになっているので、ここに保存した disk.img.tgz はDropboxクラウドやLAN同期を経由して手元のMacにも転送されます。
これでバックアップは終了です。
これらバックアップはスクリプトにして、cronで週3回ほど自動実行させています。
スクリプトはこんな感じ。バックアップ開始/終了をtwitterにpostしています。
USERNAME@SERVER:# cat backup_image.sh
(SSDが潤沢にあればこんなことしなくて良いのに!)
また、ホストマシン側は 4GBのSSDしか使用できない環境なので、今回はゲストマシン側だけで何とかします。
(SSDが潤沢にあればこんなことしなくて良いのに!!)
なお、このblogは例によってメモ for 未来の私 です。
ゲストマシン環境
ディスクマウント状態はこんな感じ
/dev/xvda3 /dataは SDHCです。
バックアップ対象は /(/dev/xvda1) だけです。
バックアップ保存先は /data(/dev/xvda3) です。
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext3 rw,noatime,nodiratime,errors=remount-ro 0 0
/dev/xvda3 /data ext3 rw,noatime,nodiratime 0 0
ホストマシン側から見ると、
/dev/xvda1 と /dev/xvda2 は EeePC 4G-X 上のSSDに保存されている ディスクイメージファイル(スパースファイル)です。
/dev/xvda3 は外付けSDHC(/dev/sdc1)です。
ホストマシン側でマウントしているデバイスはゲストマシンでマウントできないため、ホストマシンは /dev/sdc1はマウントしていません。
仮想マシン起動用のcfgはこんな感じ(抜粋)
disk = [
'file:/data_local/xen/domains/alpha/disk.img,xvda2,w',
'phy:/dev/sdc1,xvda3,w',
'file:/data_local/xen/domains/alpha/swap.img,xvda1,w',
]
バックアップ手順
1. ディスクイメージ作成
2GBのスパースファイルを作成します。
作成先は /data/tmp/disk.img です。
# dd if=/dev/zero of=/data/tmp/disk.img bs=1024M seek=2 count=0
2. ファイルシステム作成
作成したディスクイメージに ext3ファイルシステムを構築します。
対話的に y/n を聞かれることがあるので、自動的に y を答えるようにします。
# echo "y" | /sbin/mkfs -t ext3 /data/tmp/disk.img
3. 作成した空ディスクをマウント
ループバックデバイスとして作成したディスクを /mnt/tmp にマウントします。
# mount -o loop /data/tmp/disk.img /mnt/tmp
4. コピー
rsyncを使用して、/(ファイルすべて) を /mnt/tmp にコピーします。
ただし、SDHCである /data/ と マウントしている /mnt/tmp/ は除外します。
90秒スリープしているのはバッファの内容を書きこむのを待っているため。sleepしなくても良いのですが、なんとなく。
# /usr/bin/rsync -Sax / /mnt/tmp --exclude "/data/" --exclude "/mnt/tmp/"
# sleep 900
5. アンマウント
マウントを解除します。
# umount /mnt/tmp
6. GNU tarでアーカイブ
gzip や bzip2 では sparseとしての扱いが出来ずに、今回であれば 2GBのファイルとして扱ってしまいますが、sparseファイルが扱える GNU tar (Sオプション)を使い、/data/tmp/disk.img から /data/Dropbox/backup/disk.img.tgz を作成します。
# cd /data/tmp
# tar -Szcf /data/Dropbox/backup/disk.img.tgz ./disk.img
/data/Dropbox は Dropbox同期ディレクトリになっているので、ここに保存した disk.img.tgz はDropboxクラウドやLAN同期を経由して手元のMacにも転送されます。
これでバックアップは終了です。
これらバックアップはスクリプトにして、cronで週3回ほど自動実行させています。
スクリプトはこんな感じ。バックアップ開始/終了をtwitterにpostしています。
USERNAME@SERVER:# cat backup_image.sh
#! /bin/sh
set -x
TMP_DIR=/data/tmp
TMP_IMAGE=disk.img
DST_DIR=/data/Dropbox/backup
DST_FILE=disk.img.tgz
MNT_POINT=/mnt/tmp
TMP_FILE=/tmp/tmp.$$
TW_POST=/home/root/bin/twitter_post.pl
# mount check
# if mounted /mnt/tmp , this script will finish.
df | grep '/mnt/tmp$' > /dev/null
test $? -eq 0 && exit
#
if [ -f $TW_POST ]; then
HM=`date +%H:%M`
echo "disk image backup start at $HM" > $TMP_FILE
$TW_POST $TMP_FILE
rm $TMP_FILE
fi
test -f $TMP_DIR/$TMP_IMAGE && rm -f $TMP_DIR/$TMP_IMAGE
# make new 2GB sparse file
dd if=/dev/zero of=$TMP_DIR/$TMP_IMAGE bs=1024M seek=2 count=0
echo "y" | /sbin/mkfs -t ext3 $TMP_DIR/$TMP_IMAGE
# mount image
test ! -d $MNT_POINT && mkdir -p $MNT_POINT
mount -o loop $TMP_DIR/$TMP_IMAGE $MNT_POINT
# mount check
# if NOT mounted /mnt/tmp , this script will finish.
df | grep '/mnt/tmp$' > /dev/null
if [ $? -ne 0 ]; then
if [ -f $TW_POST ]; then
HM=`date +%H:%M`
echo "disk cannot mounted. abort. $HM" > $TMP_FILE
$TW_POST $TMP_FILE
rm $TMP_FILE
fi
exit
fi
# copy
/usr/bin/rsync -Sax / $MNT_POINT --exclude "/data/" --exclude "$MNT_POINT/"
sleep 900
umount $MNT_POINT
test -f $DST_DIR/$DST_FILE && rm -f $DST_DIR/$DST_FILE
(cd $TMP_DIR ; tar -Szcf $DST_DIR/$DST_FILE ./$TMP_IMAGE )
rm -f $TMP_DIR/$TMP_IMAGE
if [ -f $TW_POST ]; then
HM=`date +%H:%M`
echo "disk image backup finished at $HM" > $TMP_FILE
$TW_POST $TMP_FILE
rm $TMP_FILE
fi
2011/09/17
Xen
禅。
唐突ですが、自宅サーバを仮想化しました。
これまでも設定ファイルなどをtarで固めて外部ストレージに書きだしてバックアップとしていたのですが、いざ故障が発生してサーバ移行を強いられた時にちまちまアプリケーションをインストールして設定ファイルから環境を戻して... というのがすごく面倒くさいのではないかと、感じたからです。
これまでも自宅サーバは幾度かの世代交代を行ってきて、そのたびに数日の稼働をかけながら復旧させていたのですがあまりにも面倒臭い。
もちろん、再設定を行うことで知識は深まるメリットはあるものの、正直やっぱり面倒くさい。
ならば、いつ本体が故障して新ハードウェアになったとしても、従来の環境をガッツリ戻せたほうが便利なのではないかと、そう思ったわけです。
というわけで、禅です。
自宅サーバ2011のスペック、環境について
ASUS EeePC 4G-X (日本発売EeePC初代モデル)
CPU Intel Celeron M 900MHz の 600MHz駆動
Mem DDR2 2GB に増設
eth0を使う(wlan0ではXenが使えない)
SSD 4GB(デフォルト)
SDHC 32GB
設計(最終的な環境)
ホストマシン、ゲストマシン ともに Debian GNU/Linux 6.0(squeeze)
仮想環境はXenを使用する。(EeePCはIntel-VTなど無いので、KVMは使用できない)
ホストマシン(domain-0)は SSD上に構築。メモリ割り当ては約0.5GB
ゲストマシン(domain-U)は SSD上にイメージファイルで構築。メモリ割り当ては1.5GB
ゲストマシン用のストレージとして SDHCを物理デバイスとして使用する。
なお、このblogは例によってメモ for 未来の私 です。
Xen 4.0 インストール
他に入れたかもしれませんが、結局入っているXen関連は以下のとおりです。たぶん aptitudeが入れてくれるはずです。
debootstrapも入っています。
Xen設定
/etc/xen/xend-config.sxp で(本体)内部ネットワークにブリッジを生成するオプションを有効化(コメント外し)します。
grub設定
環境にもよりますが、Xen対応カーネルは grub的に言うと (0番目から数えて)4番目に該当するので、
/etc/grub/grub.cfg に set default="4" を書いておきます。
(menuentryの順番を書き換えて Xen対応カーネルを 0番目にして、set default="0"のままにしておくという方法もあります)
Xen-tools 設定
仮想環境構築を手助けしてくれる xen-toolsの設定ファイル /etc/xen-tools/xen-tools.conf を編集します。
変更場所は以下のとおりです。
(括弧内はもちろんこのblogのためのコメントです)
仮想イメージ作成
(ゲストマシンのIPアドレスを 192.168.1.204とした場合)
/etc/xen/SERVERNAME.cfg が作成されているはず...です。
/etc/xen/SERVERNAME.cfg設定
bootローダーを pygrub に変更します。
これをしないとXenが正常に起動しませんでした。
ホストマシンの SDHCは /dev/sdc1 として認識されているので、これをゲストマシンに
/etc/xen/SERVERNAME.cfg を編集して SDHCを割り当てます。
file:~ はイメージファイルを指定する方法、
phy:~ は物理デバイスを指定する方法です。
このへんで一度ホストマシンを再起動しておきましょう。
ゲストマシン起動
ここでいろいろインストールするもよし、あとで行うもよし。
ホストマシンのSDHC /dev/sdc1 は ゲストマシンでは/dev/xvda3 として認識されているはずなので、/etc/fstabに書いておきます。
コンソールから抜けるには Ctrl + ] を使います。
仮想(ゲスト)マシンの自動起動
ホストマシンを再起動したときにゲストマシンも自動的に起動する設定です。
/etc/xen/auto ディレクトリを作成し、その下にゲストマシンの cfgファイルを置きます。
実際にはシンボリックリンクを作成します。
ものすごく雑ですが、これでゲストマシンが作成されました。
あとはゲストマシンに apache, mysql, php, squid, postfix, bind, dhcp 他、そのたもろもろサービスをインストール&構築してサーバ環境を構築しましょう。
Have Fun!
唐突ですが、自宅サーバを仮想化しました。
これまでも設定ファイルなどをtarで固めて外部ストレージに書きだしてバックアップとしていたのですが、いざ故障が発生してサーバ移行を強いられた時にちまちまアプリケーションをインストールして設定ファイルから環境を戻して... というのがすごく面倒くさいのではないかと、感じたからです。
これまでも自宅サーバは幾度かの世代交代を行ってきて、そのたびに数日の稼働をかけながら復旧させていたのですがあまりにも面倒臭い。
もちろん、再設定を行うことで知識は深まるメリットはあるものの、正直やっぱり面倒くさい。
ならば、いつ本体が故障して新ハードウェアになったとしても、従来の環境をガッツリ戻せたほうが便利なのではないかと、そう思ったわけです。
というわけで、禅です。
自宅サーバ2011のスペック、環境について
ASUS EeePC 4G-X (日本発売EeePC初代モデル)
CPU Intel Celeron M 900MHz の 600MHz駆動
Mem DDR2 2GB に増設
eth0を使う(wlan0ではXenが使えない)
SSD 4GB(デフォルト)
SDHC 32GB
設計(最終的な環境)
ホストマシン、ゲストマシン ともに Debian GNU/Linux 6.0(squeeze)
仮想環境はXenを使用する。(EeePCはIntel-VTなど無いので、KVMは使用できない)
ホストマシン(domain-0)は SSD上に構築。メモリ割り当ては約0.5GB
ゲストマシン(domain-U)は SSD上にイメージファイルで構築。メモリ割り当ては1.5GB
ゲストマシン用のストレージとして SDHCを物理デバイスとして使用する。
なお、このblogは例によってメモ for 未来の私 です。
Xen 4.0 インストール
# aptitude install xen-linux-system-2.6.32-5-xen-68 xen-tools
他に入れたかもしれませんが、結局入っているXen関連は以下のとおりです。たぶん aptitudeが入れてくれるはずです。
debootstrapも入っています。
asatsuki@eeetan:~$ dpkg -l | grep -i xen
ii libc6-xen 2.11.2-10 Embedded GNU C Library: Shared libraries [Xen version]
ii libxenstore3.0 4.0.1-2 Xenstore communications library for Xen
ii linux-image-2.6.32-5-xen-686 2.6.32-35squeeze2 Linux 2.6.32 for modern PCs, Xen dom0 support
ii xen-hypervisor-4.0-i386 4.0.1-2 The Xen Hypervisor on i386
ii xen-linux-system-2.6-xen-686 2.6.32+29 Xen system with Linux 2.6 for modern PCs (meta-package)
ii xen-linux-system-2.6.32-5-xen-686 2.6.32-35squeeze2 Xen system with Linux 2.6.32 on modern PCs (meta-package)
ii xen-tools 4.2-1 Tools to manage Xen virtual servers
ii xen-utils-4.0 4.0.1-2 XEN administrative tools
ii xen-utils-common 4.0.0-1 XEN administrative tools - common files
ii xenstore-utils 4.0.1-2 Xenstore utilities for Xen
Xen設定
/etc/xen/xend-config.sxp で(本体)内部ネットワークにブリッジを生成するオプションを有効化(コメント外し)します。
(network-script network-bridge)
grub設定
環境にもよりますが、Xen対応カーネルは grub的に言うと (0番目から数えて)4番目に該当するので、
/etc/grub/grub.cfg に set default="4" を書いておきます。
(menuentryの順番を書き換えて Xen対応カーネルを 0番目にして、set default="0"のままにしておくという方法もあります)
Xen-tools 設定
仮想環境構築を手助けしてくれる xen-toolsの設定ファイル /etc/xen-tools/xen-tools.conf を編集します。
変更場所は以下のとおりです。
(括弧内はもちろんこのblogのためのコメントです)
dir = /data_local/xen (仮想環境のイメージファイル作成場所。お好みのディレクトリに)
size = 2Gb (仮想イメージファイルサイズ)
memory = 1536MB (割り当てるメモリ 1.5GB)
swap = 128Mb (スワップファイルサイズ)
fs = ext3 (ディスクフォーマット)
dist = `xt-guess-suite-and-mirror --suite` (Default distribution to install.)
image = sparse (スパースファイルでディスクイメージを作成)
gateway = 192.168.1.1 (ネットワーク関連設定)
netmask = 255.255.255.0 (ネットワーク関連設定)
broadcast = 192.168.1.255 (ネットワーク関連設定)
arch = i386 (CPUアーキテクチャを指定)
仮想イメージ作成
(ゲストマシンのIPアドレスを 192.168.1.204とした場合)
# xen-create-image --hostname SERVERNAME --ip 192.168.1.204おなじみのDebianインストールをして、終了させます。
/etc/xen/SERVERNAME.cfg が作成されているはず...です。
/etc/xen/SERVERNAME.cfg設定
bootローダーを pygrub に変更します。
これをしないとXenが正常に起動しませんでした。
bootloader = '/usr/lib/xen-default/bin/pygrub'
ホストマシンの SDHCは /dev/sdc1 として認識されているので、これをゲストマシンに
/etc/xen/SERVERNAME.cfg を編集して SDHCを割り当てます。
disk = [
'file:/data_local/xen/domains/alpha/disk.img,xvda2,w',
'phy:/dev/sdc1,xvda3,w',
'file:/data_local/xen/domains/alpha/swap.img,xvda1,w',
]
file:~ はイメージファイルを指定する方法、
phy:~ は物理デバイスを指定する方法です。
このへんで一度ホストマシンを再起動しておきましょう。
ゲストマシン起動
# xm create -c SERVERNAMEゲストサーバ SERVERNAME が起動して、そのコンソールに接続する... はずです。
ここでいろいろインストールするもよし、あとで行うもよし。
ホストマシンのSDHC /dev/sdc1 は ゲストマシンでは/dev/xvda3 として認識されているはずなので、/etc/fstabに書いておきます。
/dev/xvda3 /data ext3 noatime,nodiratime 0 0とりあえず shutdown させてホストマシンに戻ります。
コンソールから抜けるには Ctrl + ] を使います。
仮想(ゲスト)マシンの自動起動
ホストマシンを再起動したときにゲストマシンも自動的に起動する設定です。
/etc/xen/auto ディレクトリを作成し、その下にゲストマシンの cfgファイルを置きます。
実際にはシンボリックリンクを作成します。
# ln -s /etc/xen/SERVERNAME.cfg /etc/xen/auto/SERVERNAME.cfg
ものすごく雑ですが、これでゲストマシンが作成されました。
あとはゲストマシンに apache, mysql, php, squid, postfix, bind, dhcp 他、そのたもろもろサービスをインストール&構築してサーバ環境を構築しましょう。
Have Fun!
execute Dropbox on Text Based Linux
仮想化した自宅サーバのバックアップ方法として、ディスクイメージファイルを dropboxにアップロードする方法を検討しました。
サーバはCLIなので、TextBasedLinuxInstall を参考にインストールします。
参考に、というかそのままなのですが、ここにメモ for 未来の私。
Step-by-step versionの手順を踏みます。
1. Dropboxを利用するユーザでログイン
rootで動かすにはセキュリティ的にも不安があるので、一般ユーザでDropboxを動かすようにします。
2. wgetでソースをダウンロード
ホームディレクトリにダウンロードします。
3. tarボールを展開する...まえにチェック
tar t します
tar x します
~/.dropbox-dist/
2つのディレクトリが展開されます。
5. ランゲージ設定
環境変数 LANG を設定します。
私はCLIでしか使用しないので、'C'です。
6. dropboxd起動
dropboxdを起動すると ~/Dropbox ディレクトリを作成します。
もし、異なるディレクトリを Dropboxファイル格納ディレクトリにしたい場合は、
そのディレクトリ(/data/Dropbox など)を作成し、~/Dropbox -> /data/Dropdox などのようにシンボリックリンクを作成します。
受け皿が用意できたら心を鎮めてプロセスを起動します。
This client is not linked to any account... Please visit https://www.dropbox.com/cli_link?host_id=謎の文字列 to link this machine.
うまくいけば Linuxマシンがクライアントとして認証され、上記メッセージは停止してクライアントとしての動作が開始します。
インストールはここまで終了です。
dropboxd は一般プロセスなので、ログインして起動しなければなりません。
nohup ~/.dropbox-dist/dropboxd &
でログアウトあとでも動くようにしても良いのですが、サーバ再起動後などはログインしなおしてまた実行しなければいけません。
そこで、プロセスの有無をチェックしてなければ起動するスクリプトを 1日1回程度 cronで実行するようにします。
スクリプトはこんな感じ
USERNAME@SERVER:~$ cat /home/USERNAME/bin/exec_dropbox.sh
crontabはこんな感じ
USERNAME@SERVER:~$ crontab -l | grep dropbox
サーバ仮想化についてはまた後日...
サーバはCLIなので、TextBasedLinuxInstall を参考にインストールします。
参考に、というかそのままなのですが、ここにメモ for 未来の私。
Step-by-step versionの手順を踏みます。
1. Dropboxを利用するユーザでログイン
rootで動かすにはセキュリティ的にも不安があるので、一般ユーザでDropboxを動かすようにします。
2. wgetでソースをダウンロード
ホームディレクトリにダウンロードします。
$ cd ~/(64bit ver.の場合は wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86_64" )
$ wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86"
3. tarボールを展開する...まえにチェック
tar t します
$ tar -tzf dropbox.tar.gz4. 展開
tar x します
$ tar -xvzf dropbox.tar.gz~/.dropbox/
~/.dropbox-dist/
2つのディレクトリが展開されます。
5. ランゲージ設定
環境変数 LANG を設定します。
私はCLIでしか使用しないので、'C'です。
$ export LANG=C LC_ALL=Cログイン時に自動的に指定したいときは ~/.bashrc や ~/.profile などに この一行を入れておきます。
6. dropboxd起動
dropboxdを起動すると ~/Dropbox ディレクトリを作成します。
もし、異なるディレクトリを Dropboxファイル格納ディレクトリにしたい場合は、
そのディレクトリ(/data/Dropbox など)を作成し、~/Dropbox -> /data/Dropdox などのようにシンボリックリンクを作成します。
受け皿が用意できたら心を鎮めてプロセスを起動します。
$ ~/.dropbox-dist/dropboxd初回起動時は怪しげなURLが数秒後とに表示されるので、別マシン(Mac や Windows)のWebブラウザからリンクに移動します。
This client is not linked to any account... Please visit https://www.dropbox.com/cli_link?host_id=謎の文字列 to link this machine.
うまくいけば Linuxマシンがクライアントとして認証され、上記メッセージは停止してクライアントとしての動作が開始します。
インストールはここまで終了です。
dropboxd は一般プロセスなので、ログインして起動しなければなりません。
nohup ~/.dropbox-dist/dropboxd &
でログアウトあとでも動くようにしても良いのですが、サーバ再起動後などはログインしなおしてまた実行しなければいけません。
そこで、プロセスの有無をチェックしてなければ起動するスクリプトを 1日1回程度 cronで実行するようにします。
スクリプトはこんな感じ
USERNAME@SERVER:~$ cat /home/USERNAME/bin/exec_dropbox.sh
#! /bin/sh
# check dropbox process, exec if dropbox process isn't exist.
A=`ps -ef | grep dropbox | grep '/home/USERNAME/.dropbox-dist/dropbox' | grep -v grep | sed '/^$/d' | wc -l`
if [ $A -eq "0" ]; then
nice -n +19 /home/USERNAME/.dropbox-dist/dropboxd &
# echo "execute dropbox"
fi
crontabはこんな感じ
USERNAME@SERVER:~$ crontab -l | grep dropbox
# execute dropbox
25 8 * * * /home/USERNAME/bin/exec_dropbox.sh > /dev/null 2>&1
サーバ仮想化についてはまた後日...
登録:
投稿 (Atom)