projects / irc.git / blame
| Commit | Line | Data |
|---|---|---|
| 3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
| 2 | <HTML> | |
| 3 | <HEAD> | |
| 4 | <TITLE> [IRCServices] A discussion on the contents of the todo file (LONG) | |
| 5 | </TITLE> | |
| 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"> | |
| 12 | </HEAD> | |
| 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 | |
| 18 | </A><BR> | |
| 19 | <I>Mon Mar 19 06:32:01 PST 2001</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="001653.html">[IRCServices] [Long mail] Service won't deop a user | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="001657.html">[IRCServices] A discussion on the contents of the todo file (LONG) | |
| 24 | </A></li> | |
| 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> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 34 | <PRE>Warning: another long email... mostly due to repeating old stuff, so that | |
| 35 | people know what is being discussed. | |
| 36 | ||
| 37 | ><i> >Here onwards I'll mention "Things to think about" | |
| 38 | </I>><i> | |
| 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). | |
| 42 | </I> | |
| 43 | :<i>-) | |
| 44 | </I> | |
| 45 | ><i> >> ** "Blacklist" of evil users to prevent them from getting +o/+v | |
| 46 | </I>><i> > | |
| 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. | |
| 49 | </I>><i> | |
| 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. | |
| 55 | </I> | |
| 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. | |
| 59 | ||
| 60 | ><i> >> ** Warn about being kicked off after N password failures | |
| 61 | </I>><i> > | |
| 62 | </I>><i> >Why not put this in the help message? You could also send it after N-1 tries. | |
| 63 | </I>><i> | |
| 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. | |
| 66 | </I> | |
| 67 | No Problem :-) | |
| 68 | ||
| 69 | ><i> >> ** Use an easily-parsable log format (eg: <time> CS REG #chan Founder) | |
| 70 | </I>><i> > | |
| 71 | </I>><i> >Whats wrong with the current format? | |
| 72 | </I>><i> | |
| 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: | |
| 75 | </I>><i> | |
| 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> | |
| 77 | </I> | |
| 78 | OUCH. you're right, this is insulting to human eyes. | |
| 79 | But if this can be parsed, whats wrong with the current format? | |
| 80 | ||
| 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 | |
| 83 | ||
| 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. | |
| 88 | ||
| 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. | |
| 92 | </I> | |
| 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. | |
| 95 | ||
| 96 | ><i> >> OS REHASH command | |
| 97 | </I>><i> > | |
| 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. | |
| 101 | </I>><i> | |
| 102 | </I>><i> If/when I do implement a rehash feature, this is what SIGHUP will | |
| 103 | </I>><i> do (instead of restart). | |
| 104 | </I> | |
| 105 | Cool. | |
| 106 | Umm "if/when"? please could u put this on the todo list? :-) | |
| 107 | Anyone else in favour? | |
| 108 | ||
| 109 | ><i> >> CS Last used time for access, AKICK entries | |
| 110 | </I>><i> > | |
| 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. | |
| 113 | </I>><i> | |
| 114 | </I>><i> I'm already planning to implement this in 5.0 unless there's some | |
| 115 | </I>><i> objection. | |
| 116 | </I> | |
| 117 | No objections | |
| 118 | ||
| 119 | ><i> >>NS Show services oper/admin/root status in INFO | |
| 120 | </I>><i> > | |
| 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 | |
| 122 | </I>don't | |
| 123 | ><i> >think that either of the suggestions(the todo one and the one i just mentioned) is a good one. | |
| 124 | </I>><i> | |
| 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. | |
| 130 | </I> | |
| 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 | |
| 135 | admins and so on. | |
| 136 | ||
| 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). | |
| 140 | </I>><i> | |
| 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. | |
| 144 | </I> | |
| 145 | Knew about the former, was requesting the latter :-) | |
| 146 | ||
| 147 | ><i> >> MS MemoServ IGNORE {ADD,DEL,LIST} | |
| 148 | </I>><i> > | |
| 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. | |
| 152 | </I>><i> | |
| 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. | |
| 157 | </I> | |
| 158 | Oops, forgot about that, I don't know how I missed it. | |
| 159 | You're right. Bad suggestion. | |
| 160 | ||
| 161 | ><i> >> ** Add a way to send OperServ (and other?) commands from the shell | |
| 162 | </I>><i> > | |
| 163 | </I>><i> >This is defintely a big help. but how about just having a telnet session with services, since that would facilitate | |
| 164 | </I>an | |
| 165 | ><i> >easier access to commands, and is a seemingly good idea... | |
| 166 | </I>><i> | |
| 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. | |
| 171 | </I> | |
| 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? | |
| 175 | ||
| 176 | ||
| 177 | ><i> >> ** Services log channel | |
| 178 | </I>><i> >Was there a recent discussion on this? | |
| 179 | </I>><i> | |
| 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. | |
| 186 | </I> | |
| 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? | |
| 192 | ||
| 193 | ||
| 194 | ||
| 195 | </PRE> | |
| 196 | ||
| 197 | <!--endarticle--> | |
| 198 | <HR> | |
| 199 | <P><UL> | |
| 200 | <!--threads--> | |
| 201 | <LI>Previous message: <A HREF="001653.html">[IRCServices] [Long mail] Service won't deop a user | |
| 202 | </A></li> | |
| 203 | <LI>Next message: <A HREF="001657.html">[IRCServices] A discussion on the contents of the todo file (LONG) | |
| 204 | </A></li> | |
| 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> | |
| 210 | </LI> | |
| 211 | </UL> | |
| 212 | ||
| 213 | </body></html> |