ウェブサーバー上にシンプルだが署名されたリポジトリをセットアップするだけです。他のほとんどのチュートリアルはやや時代遅れで扱いにくいため、ここで手順を再現してみます。初期構成には少し手間がかかりますが、シンプルなビルドスクリプトにより管理が容易になります。そして、新しい*.debファイルをドロップして更新するか、cronジョブに処理させることができます。
署名キーを生成する
最初にgpg、パッケージとリポジトリの署名キーを作成する必要があります。パスワードなしで（4）RSA署名キーにし、$KEYNAME要求されたときに一意のキーにします。（その他の例ではdpkg1、キー名として「」を想定しています。）
gpg --gen-key
gpg -a --export-secret-key dpkg1 > secret.gpg
gpg -a --export dpkg1 > public.gpg
あなたのウェブサーバーには繰り返し入力するための組み込みのサルがないので、私はパスワードを言わなかった。そして、署名されたパッケージとリポジトリは、それに関するアップデート管理者の苦情を満足させることのみを目的としています。両方のキーを/apt/Webサーバーの新しいリポジトリディレクトリにアップロードするだけで、初期化後にsecret.gpgキーを削除します。
CGIスクリプトを更新する
これは、単純な更新シェル/ CGIスクリプトです。
#!/bin/sh
echo Status: 200 Okay
echo Content-Type: text/plain
echo
echo Rebuilding APT repository:
{
#-- settings
export GNUPGHOME=/var/www/usr12345/files
export KEYNAME=dpkg1
#-- one-time setup
if [ ! -e "$GNUPGHOME/secring.gpg" ] ; then
gpg --import -v -v ./secret.gpg
gpg --import -v -v ./public.gpg
gpg --list-keys
fi
#-- symlink .deb files from adjacent sub-directories
find .. -name '*.deb' -exec ln -s '{}' . \;
#-- build Packages file
apt-ftparchive packages . > Packages
bzip2 -kf Packages
#-- signed Release file
apt-ftparchive release . > Release
gpg --yes -abs -u $KEYNAME -o Release.gpg Release
} 2>&1
この3 gpg行は、あるディレクトリ$GNUPGHOME（ドキュメントルートの上）でGPGセットアップを初期化するために1回だけ実行する必要があります。secret.gpg成功後のみ削除します。
この小さなシェルスクリプトのユニークな機能の1つは、*.debドロップインするファイルを受け入れるだけでなく、再帰的に（1レベル上から）他のファイルを検索し、シンボリックリンクすることです（Options FollowSymLinks最終的には.htaccessが必要です）。
このスクリプトは、CGIとして手動で実行することも、cronジョブごとに実行することもできます。ただし、非表示にするか、ドキュメントルートから移動することをお勧めします。
「簡単な」aptリポジトリであるため、次のapt-sources.listエントリが必要です。
deb http://example.org/deb/ ./ # Simple signed repo
これは、単一アーキテクチャのリポジトリに適しています。数百のパッケージを期待しない場合。
パッケージ署名
gpgキーを設定したら、個々のパッケージに署名することも簡単です。
dpkg-sig -k dpkg1 -s builder *.deb
（これは、リポジトリWebサーバーではなく、パッケージがビルドされるワークステーションで実行する必要があります。）
署名のないリポジトリ
署名されたパッケージが必要ない場合は、更新スクリプトを次のように削減できます。
dpkg-scanpackages . > Packages
bzip2 -kf Packages
これはまだ平均的なユーザーが使用できますが、次のカスタムフラグが必要ですapt.sources。
deb [trusted=yes] http://apt.example.org/deb/ ./
しかしtrusted=yes、すべてにフラグを習慣的に使用しないでください。または、パッケージの起源が実際にわからない場合は。
使いやすさのために
エンドユーザーの場合HEADER.htmlは、リポジトリディレクトリにドロップします。Apache mod_auto_indexはそのメモを先頭に追加します：
<h1>http://example.org/apt/</h1>
<dl>
<dt>Add this repository to /etc/apt/sources.list as:
<dd><kbd>deb http://example.org/apt/ ./ # example repo</kbd>
<dt>Import verification key with:
<dd><kbd>wget -q http://http://example.org/apt/public.gpg -O- | sudo apt-key add -</kbd>
</dl>
代替案
最近、リポジトリ管理を自動化するいくつかのツールがあります。そして、さえリポジトリオンラインホスティング事業者とパッケージのビルドサービス（あるgemfury、packagecloudは、bintrayなど）
かなり便利な代替手段はprmです。複雑なAPTおよびYUMリポジトリを作成するRubyスクリプトです。（ただし、RPMがやがてやがて消滅することを願っています。）-ごとにインストールするのが最適gem install prmです。
また、これを同様に自動化する小さなスクリプトを作成しました：http : //apt.include-once.org/apt-phparchive-過度に堅牢ではなく、PHPで書かれていることに注意してください（一度、これは偶然です）もともとはDEB、RPM-over-APTおよびPharバンドル向けでした。
これは元の質問と密接に関連しているため、Debianパッケージをより簡単に構築するツールもあります。やや時代遅れ：EPM。さらに多くのcontempoary：FPM。そして、私の個人的なフォーク：XPM（スクリプト言語アプリをパッケージ化するためのより怠approachなアプローチ。）