1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] A discussion on the contents of the todo file (LONG)
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20A%20discussion%20on%20the%20contents%20of%20the%20todo%20file%20%28LONG%29&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"001653.html">
11 <LINK REL=
"Next" HREF=
"001657.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] A discussion on the contents of the todo file (LONG)
</H1>
15 <B>Imran Ali Rashid
</B>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20A%20discussion%20on%20the%20contents%20of%20the%20todo%20file%20%28LONG%29&In-Reply-To="
17 TITLE=
"[IRCServices] A discussion on the contents of the todo file (LONG)">u970042 at giki.edu.pk
19 <I>Mon Mar
19 06:
32:
01 PST
2001</I>
21 <LI>Previous message:
<A HREF=
"001653.html">[IRCServices] [Long mail] Service won't deop a user
23 <LI>Next message:
<A HREF=
"001657.html">[IRCServices] A discussion on the contents of the todo file (LONG)
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#1639">[ date ]
</a>
27 <a href=
"thread.html#1639">[ thread ]
</a>
28 <a href=
"subject.html#1639">[ subject ]
</a>
29 <a href=
"author.html#1639">[ author ]
</a>
34 <PRE>Warning: another long email... mostly due to repeating old stuff, so that
35 people know what is being discussed.
37 ><i> >Here onwards I'll mention
"Things to think about
"
39 </I>><i> I should point out that many of the things listed here I myself don't
40 </I>><i> entirely agree with, but listed anyway to consider later and hopefully
41 </I>><i> generate comments (like these).
45 ><i> >> **
"Blacklist
" of evil users to prevent them from getting +o/+v
47 </I>><i> >Isn't this already there ala access list autodeop. set the nojoin level to -
2 and use this at -
1.
48 </I>><i> >As far as novoice goes, it could be added the same way autodeop is there.
50 </I>><i> You're misunderstanding this. This is not on a per-channel basis,
51 </I>><i> but something that applies to a user or users on the entire network, no
52 </I>><i> matter what channel they are in. In particular, I was thinking that
53 </I>><i> hostmasks could be used here to deal with people (or bots) who don't
54 </I>><i> register their nicks and get other people to op/voice them.
56 Isn't this a channel issue, which can be dealt with using secureops and a good access
57 list? I mean, if they get opped and people in the channel don't like it, its a channel issue,
58 so why should it be considered globally.
60 ><i> >> ** Warn about being kicked off after N password failures
62 </I>><i> >Why not put this in the help message? You could also send it after N-
1 tries.
64 </I>><i> The second is already what I'm thinking of doing, but the first is
65 </I>><i> a good idea as well, thanks.
69 ><i> >> ** Use an easily-parsable log format (eg:
<time
> CS REG #chan Founder)
71 </I>><i> >Whats wrong with the current format?
73 </I>><i> It's not as easy to parse programmatically as it could be. For
74 </I>><i> example, some people have suggested something like:
76 </I>><i> 03/
02/
2001:
12:
34:
56 N R NickName
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">user at somehost.net
</A> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">email at add.ress
</A>
78 OUCH. you're right, this is insulting to human eyes.
79 But if this can be parsed, whats wrong with the current format?
81 [Mar
19 08:
29:
48 2001] NickServ: aala-hazrat!
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">Stud at altamash.hostel4.giki.edu.pk
</A>
82 identified for nick aala-hazrat
84 You can still use the first word after the braces end to know if its nickserv or not.
85 registered is the second word after the : if register is being talked about. I don't think
86 the second word starts with 'r' in any other scenario. The rest can easily be parsed
87 since you already know which word has the nick and mask.
89 ><i> One thing I'm considering is to (optionally, of course) keep two
90 </I>><i> logfiles: one the same as now, and one with the new format containing
91 </I>><i> only registrations/identifies/drops and similar events.
93 Ummm why another log file... As i mentioned above, it can still be parsed easily.
94 A little extra effort is required, but not as much as people think.
96 ><i> >> OS REHASH command
98 </I>><i> >Please Please Please put this in.
99 </I>><i> >and umm a slightly different behaviour as compared to the SIGHUP signal.
100 </I>><i> >I refer to the fact that everyone has to identify again.
102 </I>><i> If/when I do implement a rehash feature, this is what SIGHUP will
103 </I>><i> do (instead of restart).
106 Umm
"if/when
"? please could u put this on the todo list? :-)
107 Anyone else in favour?
109 ><i> >> CS Last used time for access, AKICK entries
111 </I>><i> >This is a good idea. This was even mentioned by someone recently.
112 </I>><i> >So lets discuss it and see how many people like it.
114 </I>><i> I'm already planning to implement this in
5.0 unless there's some
115 </I>><i> objection.
119 ><i> >>NS Show services oper/admin/root status in INFO
121 </I>><i> >I don't see why this is necessary... If you want to let people know who is what, make it a separate command. But I
123 ><i> >think that either of the suggestions(the todo one and the one i just mentioned) is a good one.
125 </I>><i> I don't see why it's a _bad_ suggestion, though with the newer
126 </I>><i> servers which support +a (Services admin) mode it's not as necessary
127 </I>><i> anymore. My aim with this is to let people know who they can go to
128 </I>><i> when they have problems with Services--though of course that's really
129 </I>><i> a network policy matter more than anything, I suppose.
131 If you want to announce who the services admin is, there are easier ways, ala
132 motd and logonnews. Why put it in his nickserv info. This is not a good idea
133 from a security point of view, and like I said, if you want something extra to let
134 people know who to go to, put in a separate command, that lists active services
137 ><i> >Even the channel founder is sometimes baffled, since he can't find out. You have to go to a services admin.
138 </I>><i> >Why not add a command to let people know which nicks are linked to theirs(after identifying of course), and add
139 </I>><i> >something to chanserv to let people know how a person got opped(the linked nick being a case in point).
141 </I>><i> The former is already present, though only usable by Services
142 </I>><i> admins (NickServ LISTLINKS). The latter has been requested by other
143 </I>><i> people as well, and I'll look into implementing it for version
5.0.
145 Knew about the former, was requesting the latter :-)
147 ><i> >> MS MemoServ IGNORE {ADD,DEL,LIST}
149 </I>><i> >If a person wants to irritate you and u put him on ignore, whats to stop them from getting another nick and sending
150 </I>><i> >another memo? to help against this and cases of memo flooding, a command may be put in to get rid of the memos of a
151 </I>><i> >certain nick.
153 </I>><i> Since you can already delete ranges of memos with a single
154 </I>><i> command, I don't see the benefit of this. As for the usefulness of
155 </I>><i> IGNORE, as someone else also pointed out, ignoring
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">user at host
</A> masks
156 </I>><i> will prevent the register-a-new-nick problem.
158 Oops, forgot about that, I don't know how I missed it.
159 You're right. Bad suggestion.
161 ><i> >> ** Add a way to send OperServ (and other?) commands from the shell
163 </I>><i> >This is defintely a big help. but how about just having a telnet session with services, since that would facilitate
165 ><i> >easier access to commands, and is a seemingly good idea...
167 </I>><i> Although I haven't decided on exactly how, I hope to implement
168 </I>><i> something like this for version
5.0. Obviously, there are security
169 </I>><i> concerns associated with allowing remote access, which I'll have to
170 </I>><i> consider as well.
172 how about
127.0.0.1 access only and having a password specially set
173 by the services admins for this purpose via irc or otherwise, which is
174 encrypted. What else is a concern from a security point of view?
177 ><i> >> ** Services log channel
178 </I>><i> >Was there a recent discussion on this?
180 </I>><i> Not recent, but a long time ago there was some discussion about
181 </I>><i> this. As I recall, it essentially came down to the benefit of being
182 </I>><i> able to monitor the log online (remotely) vs. the security problems of
183 </I>><i> having Services status information broadcast on the network and the
184 </I>><i> additional network load. I personally think it would be better off
185 </I>><i> not being added, but I'm open to comments.
187 As such, if there is access to the server on which services is hosted, then
188 this suggestion is useless, but if access is a problem, then this seems to
189 be a good idea to help with troubleshooting, and the same way, rotatelog
190 would seem helpful.. By the way, I know its still there via SIGUSR2 but why
191 was it removed from operserv?
201 <LI>Previous message:
<A HREF=
"001653.html">[IRCServices] [Long mail] Service won't deop a user
203 <LI>Next message:
<A HREF=
"001657.html">[IRCServices] A discussion on the contents of the todo file (LONG)
205 <LI> <B>Messages sorted by:
</B>
206 <a href=
"date.html#1639">[ date ]
</a>
207 <a href=
"thread.html#1639">[ thread ]
</a>
208 <a href=
"subject.html#1639">[ subject ]
</a>
209 <a href=
"author.html#1639">[ author ]
</a>
projects / irc.git / blob