[newdak/master] Initial feature.txt
*VERY* incomplete intial feature.txt added. A starting point,
but only about 10% written down yet.
Signed-off-by: Joerg Jaspert <joerg@debian.org>
---
ChangeLog | 4 ++
feature.txt | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 ChangeLog
create mode 100644 feature.txt
diff --git a/ChangeLog b/ChangeLog
new file mode 100644
index 0000000..7ac5d5a
--- /dev/null
+++ b/ChangeLog
@@ -0,0 +1,4 @@
+2008-08-30 Joerg Jaspert <joerg@debian.org>
+
+ * feature.txt: Added *initial* and very uncomplete version.
+
diff --git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..15bb186
--- /dev/null
+++ b/feature.txt
@@ -0,0 +1,121 @@
+Feature Desc / Roadmap for a DAK Rewrite
+========================================
+
+Item "Levels"
+-------------
+* Major, must-have (AKA RC) point
++ Should be there
+- Would be nice, but we can live without it
+= If, ever, someone is bored, ...
+N Not done. Won't happen. Can't hear you. LALALA. Go away.
+X Done.
+
+Every Item should have a short header, followed by a description of it.
+The header should be of a form like
+* DESC WHO WHEN
+ie. "Level, Description, Who added it, When was it added".
+
+When we are done with one, mark it X and add the done date too.
+If you work on something and it takes longer - mark it.
+
+
+Global
+------
+
+* Completly modular. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ For example, if we want to extend the Changes-Formats known by DAK, it should
+ be enough to drop one file into a directory and have it. Same goes for
+ supported compression algorithms. Or whatever else.
+
+* OO / Coding Style. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ Use the Object Oriented foo Python offers as far as possible.
+ Also, consistent coding style. Spaces for indents, readable *and*
+ self-explaining variable names, ...
+ (Mhy: extend)
+
+* Client/Server style. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ There should be one "dakd" running, thats doing everything. FTPMaster
+ (and cron), everything uses client-scripts talking to dakd, asking it
+ to do whatever one wants to do.
+ This needs a proper protocol description.
+
++ Multi-Archive aware. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ As we are going to have a server speak via TCP (or unix sockets, both
+ possible), new DAK should be multi-archive aware, possibly
+ (setup-depending) communicating in both ways.
+
+
+New database design (Mhy: Your text here)
+-------------------
+
+DAK server AKA dakd
+-------------------
+
+ * Listens on some high-port. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ We have to have unix sockets, but we want to be network open, so some
+ high port...
+
+ * Protocol. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ We need a protocol where clients can talk to dakd. We might either go
+ and develop an own one or use some xmlrpc or soap or whatever
+ existing foo.
+ Basically we need to be able to easily do things like
+ "install foo.changes"
+ "rm blapkg"
+ "list package foo suite bar"
+
+ * Proper SSL Implementation. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ The server has to have a proper ssl implementation. We want to be
+ able to go multi-archive and/or allow remote queries of it, this
+ should be properly secured.
+
+ * Full SSL auth (Server *and* Client cert) is required for any action
+ that does any write operation. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+
+ * SSL Server identification/authentification. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ So clients can verify they are talking to the server they want. Mandantory.
+
+ * SSL Client authentification. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ So the Server knows who he speaks to. Client auth is optional, no
+ client cert means anonymous mode and only readonly querying of
+ dak. Every archive and every ftpteam member needs own client cert.
+
+ + Optional non-SSL connections. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ They are strictly limited to the most basic read
+ operations. Basically dak ls only. Maybe equivalent of "dak rm -nR" too.
+
+ * Proper rights management. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ The whole rights management has to be within dakd. The whole
+ database, all directories, everything, should only be modified by
+ dakd. No more unix access rights on files or different groups within
+ postgres to limit actions taken.
+
+ + Everything in the archive is managed by dakd. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ This includes every byhand file. Nothing that ends up in the public
+ viewable mirror space should *ever* be copied in by hand from an FTPMaster.
+
+
+General Archive Issues
+----------------------
+
+ * Changed file/directory layout. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ No longer write directly into pool/ on accept time. Instead write
+ everything into a files/$HASHED location, then hardlink over.
+ $HASHED will be:
+ - calculate sha256sum of the file.
+ - take the first (or last?) 6 chars of the sum, build a 3-level
+ directory tree with it.
+ - Store file in there.
+ Ie. taking the current README from ftp/ we have
+ e945e7d156d770ec26d742499cb119e52fe3de963f0bc3bdc42132d29c2fcbe8 README
+ so it will be stored in
+ files/e9/45/e7/e945e7d156d770ec26d742499cb119e52fe3de963f0bc3bdc42132d29c2fcbe8
+ and then hardlinked over to ftp/README.
+
+ * "NIv2". [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
+ No longer have a queue/accepted where everything gets first, and then
+ moved over on dinstall time.
+ Instead move files directly into the files/ location, do everything
+ right in the database(s). "Dinstall" then merely updates packages
+ files and triggers the main w-b run.
+
--
1.5.6.3
Reply to: