File: TODO

package info (click to toggle)
linuxconf 1.26r4-2
  • links: PTS
  • area: main
  • in suites: woody
  • size: 56,432 kB
  • ctags: 27,217
  • sloc: cpp: 158,803; perl: 7,484; sh: 4,134; java: 3,105; ansic: 2,492; makefile: 2,216; python: 109
file content (206 lines) | stat: -rw-r--r-- 5,801 bytes parent folder | download | duplicates (2)
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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
bugs:

	/var/lib/zoneinfo is a real file instead of a link

general:

	Support token ring

	package RPM

	Support PCMCIA and multiple configuration

	view syslog

	X interface

	Add a menu to show what is still not configured. This alone
	may save the day of the administrator (user). It is expected
	that linuxconf will grow and grow, one day allowing dynamic
	linkage with addon module. Its cute menu scheme will become
	a large network where new user may get lost.

	Sequential install mode.

		Add a menu where the user is guided from menu to menu
		to do a basic configuration. This menu will be always
		available. There must be a way to force askrunlevel into
		that menu a boot time. Call this an unconfigure option
		which erase nothing but force the user to inspect/correct
		the most important configuration option.

	Add a revision number for subsystem. When a subsystem is
	visited by the admin, the revision is stored in /etc/conf.linuxconf.
	When the admin upgrade linuxconf, linuxconf can check the revision
	numbers and if some sub-system have a new number, linuxconf may
	force the admin to look at the new features. Ultimatly, this
	would replace the sequential install mode above.
	This would be a major feature for dropins. You drop it. If linuxconf
	do not tell you anything, then this is because there is nothing
	special to adjust.


	Add runlevel information in dropin (Which runlevel they should be
	enable). Do the same for graphical operation mode. So a dropin is
	controlled by network mode, graphic mode and runlevel. The interface
	will need a way to define an "Any" value for those fields.

	Add a boot command to dropin. This command will be run at boot
	time to do some cleanup.

	Add a monitor command to dropins. A monitor command is used to
	decided if a dropin has to be activated/reactivated/whatever. This
	is useful when a dropin control something which is not a process.
	The monitor command would run and return something like

		0: all is ok
		1: Run the start command
		2: Run the restart command or run the stop and then the start command
		3: Run the stop command

		This would not be that efficient, and potentially should be
		done with a module, but this could be useful for "on site"
		dropin creation where one is trying to control something
		custom with a dropin

dnsconf:

	Nom absolue dans une zone csm.qc.ca.	IN	A ...

	Global inspector

	This modules would be able to do several test to validate the
	configuration of the machine and check how it relates to other
	machine in the network. Different tests could be done to
	detect problems.

	-For each primary, query the configuration in the DNS and make
	 sure, using another DNS that this DNS is really the authority.

	-Make sure these is a reverse mapping for every A record of the
	 DNS.

	-Make sure secondaries are indeed doing their job and are up to date.
	 Make sure the announced secondaries in the zone file are the same
	 which were registered with the parent domain (internic).

	-Make sure the MX record points to machine which knows how to
	 deal with this domain (difficult to automate). Maybe linuxconf
	 should generate sendmail configuration which let probe the domain
	 which are managed by this host. Security hole ? Why not let
	 linuxconf itself answer this query maybe.

	-For a mail server, consult the name of all its interface and
	 make sure the sendmail.cf accept email for every name.

	-Make sure the mail gateway may be reach and is a valid DNS name
	 Same thing for the mail server.
	

netconf:

	/etc/netmasks not supported

	host.conf
		Unsupported fields
		- alert on
		- nospoof on
		- reorder  

	NIS server

	slip setup

	inetd.conf and services management

	hosts.allow and friends

	PPP dialout

		Check for \ in the init chat script and prompt the user to
		use \\ as needed.

lpconf:

	Still to do

userconf:

	/etc/porttime should be managed by linuxconf.

	PPP acount should let the configuration of pppd option right
	from the dialog. No need for a special ppplogin script (although
	this options should be available, ie, using your own ppplogin scheme).

	When deleting a user account, linuxconf should propose to archive
	the home directory and the email folder. It should manage the
	file /etc/passwd.deleted and /etc/shadow.deleted if it exist.

	More validation of user name (maximum length, no numeric at the
	beginning). Allow the configuration of an external script for

		validation of the user name
		password auto-generation
		Special action when creating the home directory
		Site validation and post creation scripts

	locking user account insert a * in the password instead of overwriting
	it completly. This would allows locking/unlocking account even for non
	shadow system.

admin-fs:

	Turning all this into a virtual file system :-)


inittab:

	Management of getty and mgetty

mail:

	vpop3d should identify connection to the host over connection
	to a virtual domain when the host is part of the virtual domain
	itself (weird).

	precedence bulk for vdeliver

askrunlevel:

	Configuration of /etc/inittab (especially for common
	task like activating a modem)

	/sbin/init should be modified to support run sets where 
	many runlevel may be active at one. I guess it is a pretty
	easy modification. It would make runlevel so much more useful

	For exemple:

		runlevel 1: ppp services
		runlevel 2: modem services
		runlevel 3: basic console getty
		runlevel 4: Extra console

	So full multiuser would be 1+2+3+4+5+6

	Well, just an idea

fsconf:

	swap setup

uucp:

	Interactive test mode
	Better report than what is usually available with uucp.
		-Report can be sent by email every once in a while
		 and also saved into some log for later perusal

xconf:

	xdm management of xterminal

mailconf:

	Trust users management