1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
This is a living document, it may change at will of the developers and is in no
way definitive. It should be considered as a collection of random
thoughts from the developers, that may or may not make sense. :-)
Version 0.2 and before.
This is what I consider the testing phase of PureAdmin. It
will basically use the existing architecture and design to
allow everything currently in PureAdmin. Including
* Activities: Viewing "real-time" activities on server
* Log file: Views relevant PureFTPd logging in a colored
text area.
* Kick connected users.
* Start/Stop server.
* Edit users (puredb)
- Add new users
- Remove existing users
- Change user info for existing users.
All of the above is currently implemented, and working. All
we're waiting for before a 0.2 "stable" release is to sort out
all existing bugs. This seems to be close now!
Version 0.3 and beyond
When 0.3 (unstable) is out, it will be a split of the backend
and frontend. Not only does this clean up the code a bit, but
it also presents a more flexible ground to build features.
New possibilities with the new design includes (but are not
limited to):
* Multiple GUIs could be written, such as GTK+,
QT/KDE, ncurses etc.
* Special purpose apps could be written, such as panel
applets, notification daemons.
* GUI can run on another machine than the ftp-server
is running at.
The plan is to have a server process running at all time (or
on demand(tm)) that does the real work talking to PureFTPd and
fetching information on the servers whereabouts. This include
users, activities, logging etc.
The daemon will listen for connections/requests on a socket
(local Unix or inet), and clients use a defined protocol to
speak to the daemon.
SECURITY
========
While this sure presents some benefits, it also requires more
security measures. We don't want a daemon that accepts any
program to connect and control the ftp-server. This would be
an obvious security flaw!
First of all, we need an opt-in type of security
configuration, where unless otherwise explicitly stated, an
action will be prohibited!
USE CASES
=========
As I see it, there are two major use-cases to consider with
this approach:
1) Ftp server running on the same machine as PureAdmin.
1.1) PureAdmin daemon not running,
1.2) PureAdmin daemon already running.
2) Server running on another machine than PureAdmin.
I believe that 1) is the normal case, and we should provide a
solution that just works(tm) for this approach. If someone is
in the 2nd category, then we have to assume that he/she knows
a bit about computers and security to get things up and
running.
Use case 1)
-----------
From the users point of view, PureAdmin should behave the same
way as version 0.2 and before. If the daemon isn't running, it
should be launched and setup-ed to allow local connections
with all features enabled. This may or may not require root
access.
On the other hand, if a daemon is already running, try
connecting to it. If this doesn't succeed, eventually try
launching a new daemon process.
With this approach, I think that a local socket should be
used. This way, we rely on the operating system kernel to make
sure that no "outsider" can manipulate the ftp server.
It should be possible, from within the GUI, to connect to a
PureAdmin daemon running on another machine, to use it as
described in Use case 2). Perhaps even a command line switch
and/or configuration option to default to this behavior.
Use case 2)
-----------
This would require a manual compilation and installation of
PureAdmin daemon to the machine running the ftp server. It is
also necessary to start the daemon manually and make sure it
is configured properly. A hard-coded config should be used if
none is present.
Jörgen should be able to provide more insight to this issue,
since he is more involved in security, sockets and network
programming than I am.
Ok, this should do for now. I'll update this document as soon as new
ideas pop up!
Isak Savo, 2004-11-15, 14:42 GMT+0100
|