UnrealIRCd Bug Tracker

3955

installing

block

always

2010-09-07 17:02

2010-09-08 13:47

chotaire

ohnobinki

normal

feedback

3.2.8.1

none

x86

QNX

6.5.0

3.2.8

reopened

Modifications to source necessary to compile on QNX 6.5.0

The following modifications were necessary to successfully compile Unreal 3.2.8.1 on QNX 6.5.0, as seen by compile errors:

-----------------------

gcc -I../include -I/home/irc/ircd-nassau/extras/regexp/include -I/home/irc/ircd-nassau/extras/c-ares/include -L../extras/c-ares/lib -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -export-dynamic -DFD_SETSIZE=900 -c timesynch.c
In file included from ../include/common.h:46,
                 from ../include/struct.h:43,
                 from timesynch.c:21:
../include/sys.h:47:23: error: sys/errno.h: No such file or directory
make[1]: *** [timesynch.o] Error 1
make[1]: Leaving directory `/home/irc/ircd-nassau/src'
make: *** [build] Error 2

I changed <sys/errno.h> to <errno.h> in include/sys.h and it will continue compiling just fine.

-----------------------

gcc -I../include -I/home/irc/ircd-nassau/extras/regexp/include -I/home/irc/ircd-nassau/extras/c-ares/include -L../extras/c-ares/lib -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -export-dynamic -DFD_SETSIZE=900 -c s_bsd.c
s_bsd.c: In function 'init_sys':
s_bsd.c:644: error: too many arguments to function 'setpgrp'
make[1]: *** [s_bsd.o] Error 1
make[1]: Leaving directory `/home/irc/ircd-nassau/src'
make: *** [build] Error 2

I change line 644 to:
        (void)setpgid(0,(int)getpid());

It's also possible to change line 644 to:
        (void)setsid();

-----------------------

After which it will compile just fine without any warnings.

ohnobinki

2010-09-07 17:40

- Don't use sys/errno.h, as it's not POSIX and breaks on QNX-6.5.0. (0003955)

Thanks very much for the report :-).

chotaire

2010-09-07 18:12

One issue missed during resolve.

syzop

2010-09-08 13:05

I see:

#if defined(HPUX) || defined(_SOLARIS) || \
    defined(_POSIX_SOURCE) || defined(SVR4) || defined(SGI) || defined(OSXTIGER)
        (void)setsid();
#else
        (void)setpgrp(0, (int)getpid());
#endif

What exact change do you suggest?

a defined(..QNXSOMETHING..) added to the first #if ?

I've now added an || defined(__QNX__)

Could you check that fixes it? :

#if defined(HPUX) || defined(_SOLARIS) || \
    defined(_POSIX_SOURCE) || defined(SVR4) || defined(SGI) || \
    defined(OSXTIGER) || defined(__QNX__)
        (void)setsid();
#else
        (void)setpgrp(0, (int)getpid());
#endif

Thank you very much for testing QNX by the way, glad to hear it works after these few adjustments :)

chotaire

2010-09-08 13:47

I'll check CVS shortly. If there is any remaining issues regarding QNX (also concerning the fixtimer issue), I will let people know.

As for the timing issue, I had already patched the source myself (bad hack though but it works) and you might enjoy to know that there is now one live IPv6+SSL unrealircd server running on QNX (never heard of any ircd on QNX before). Implementing the IPv6 stack was quite a headache though but after all it works just great. I love QNX.

3956

ircd

major

always

2010-09-07 17:17

2010-09-08 13:07

chotaire

syzop

normal

resolved

3.2.8.1

none

x86

QNX

6.5.0

3.2.8

fixed

Timing issue on QNX 6.5.0 in ircd.c

When starting unrealircd on QNX 6.5.0, everything seems to work just fine until taking a peak into ircd.log:

[Thu Sep 2 02:19:41 2010] - TIME SYNCH: timeserver=1283818771, our=1283386781, offset = 431990 [old offset: 37]

[Tue Sep 7 02:19:31 2010] - WARNING: Time running backwards! Clock set back ~-1283818771 seconds (0 -> 1283818771)
[Tue Sep 7 02:19:31 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:31 2010] - [TimeShift] The (IRCd) clock was set backwards. Waiting for time to be OK again. This will be in -1283818771 seconds
[Tue Sep 7 02:19:34 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818771 -> 1283818774)
[Tue Sep 7 02:19:34 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:37 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818774 -> 1283818777)
[Tue Sep 7 02:19:37 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:40 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818777 -> 1283818780)
[Tue Sep 7 02:19:40 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:43 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818780 -> 1283818783)
[Tue Sep 7 02:19:43 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:46 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818783 -> 1283818786)
[Tue Sep 7 02:19:46 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:49 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818786 -> 1283818789)
[Tue Sep 7 02:19:49 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:52 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818789 -> 1283818792)
[Tue Sep 7 02:19:52 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:55 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818792 -> 1283818795)
[Tue Sep 7 02:19:55 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:19:58 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818795 -> 1283818798)
[Tue Sep 7 02:19:58 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:20:01 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818798 -> 1283818801)
[Tue Sep 7 02:20:01 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:20:04 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818801 -> 1283818804)
[Tue Sep 7 02:20:04 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!
[Tue Sep 7 02:20:07 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818804 -> 1283818807)
[Tue Sep 7 02:20:07 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze!

System clock has been verified to run quite ok. It does lag behind a second every few minutes when running as virtual machine but I fixed this using regular ntpdate updates from local timeserver so the system clock is at no time ever lagging behind more than one second. kern.hz setting or similar seems to be read-only on QNX.

This problem with ircd.c seems to prevent autoconnect for links (it just doesn't happen). If however manually linking the server, there is never any message about "PLEASE SYNC YOUR CLOCKS!" and similar. When linked, I see no problems on IRC network other than flooding local opers with notices (see ircd.log above) every 3 seconds.

Compile unrealircd 3.2.8.1 on QNX 6.5.0 and ./unreal start ; tail -f ircd.log.

ohnobinki

2010-09-07 17:28

Is this a dupe of 0003853?

chotaire

2010-09-07 18:10

For the autoconnect issue only.

syzop

2010-09-08 13:07

[Thu Sep 2 02:19:41 2010] - TIME SYNCH: timeserver=1283818771, our=1283386781, offset = 431990 [old offset: 37]

that's quite a lot :)

[Tue Sep 7 02:19:31 2010] - WARNING: Time running backwards! Clock set back ~-1283818771 seconds (0 -> 1283818771)

this is a bug, timeofday is zero the first time... what I don't understand though is how it could have triggered...

if (timeofday - oldtimeofday < NEGATIVE_SHIFT_WARN) {

if (<something> - 0 < -somethingelse)
that would be very odd :P

unless, TS / time_t on QNX is unsigned ?

that might explain the rest of the messages too..

Ah yes...
"The consensus is for time_t to be signed, and this is the usual practice. The software development platform for version 6 of the QNX operating system has an unsigned 32-bit time_t, though older releases used a signed type."

Fun.

Ok, I've fixed this in CVS [.877]:
- Fixed another compile problem on QNX, reported by chotaire (0003955 too).
- Fixed incorrect messages regarding clock going backwards on QNX 6 and
later, reported by chotaire (0003956).

Thanks for the report.

If that somehow didn't fix it, let us know.

3957

ircd

minor

sometimes

2010-09-07 19:05

2010-09-08 12:39

chotaire

normal

new

3.2.8.1

none

x86

Linux

2.6.34

3.2.8

open

Remote server disconnects do not get broadcasted via notice

Remote connects get noticed perfectly fine. However, remote disconnects do no longer get noticed (it worked in Unreal 3.1.*) unless the oper is on the server that the target server disconnected from.

Connect to server A, oper up as network admin. Receive a snomask of +kcfFjveGnNqSso (all flags). Connect server C to server B on your network. Now oper up on server C and issue /die <password>. Oper on Server A will not receive any disconnect notice and will only realize if checking /links or /map. The same applies if just rebooting the machine for server C. The only occasion it is noticed when someone remotely SQUITs.

chotaire

2010-09-07 19:06

chotaire

2010-09-07 20:09

From what I see in source, this problem exists if the servers link via SSL links. Oper on Server B will receive a disconnect notice if SNO_JUNK is set, oper on server A will definitely not.

Code can be found in ssl.c starting at line 684. While exiting clients properly get forwarded to people with snomask +F, exiting servers do not. Wanna fix?

chotaire

2010-09-07 21:06

I just tested this thoroughly, it works fine with unencrypted links. It does not work with SSL links at any time. Happy fixing ;)

chotaire

2010-09-07 21:28

Missing global notice:
*** Global -- from x.y.z: Server u.v.w closed the connection.

syzop

2010-09-08 12:39

There was -something- fixed related to this, I thought post-3.2.8.1.

If the issue still exists in CVS, then it should be fixed before 3.2.9 release.

2973

ircd

minor

always

2006-06-15 08:09

2010-09-06 15:07

vonitsanet

ohnobinki

normal

assigned

1.1.1.1.2.1.2.1.2.2234.2.537

none

FreeBSD

3.2.5

open

override bug

As netadmin with override i cant DEOP a user if i have (+h or) +o or +a ->
[15:56:48] * Netadmin sets mode: +oao Netadmin user user
/mode #test -o user

and then the error:
o user is a channel admin

if i dont have any modes (h,o,a) i can override just nice and with +o i can -a.
The problem is on DEOP.

Another (if netadmin with override is halfopped and not opped on the channel):

o user is a channel admin
h user is a channel admin
a user is a channel admin

You can give channel modes to a user with override.
The problem is when you try to remove them.

JasonTik

2006-06-15 16:10

I have to say, I've never had this problem.

Sure your netadmin, not servicesadmin or etc?

vonitsanet

2006-06-15 20:31

ME is using modes +iowghraAsRTxNWqztGp

Zell

2006-06-19 01:53

I'll be d**mned. It happens on 3.2.5, too.

I was +h at channel, and every operator flag known to God and man set.
I set my net comanager +q on the channel and me +h, and tested this out.
Results:
q tigger-away is channel owner
a tigger-away is channel owner
o tigger-away is channel owner
(when user was +q at channel)
a tigger-away is channel admin
o tigger-away is channel admin
(when user was +a at channel)

vonitsanet

2006-06-19 22:24

Exactly

WolfSage

2007-04-15 20:44

Just tested, and verified. I think this should be fixed in 3.3.

2535

documentation

minor

always

2005-05-25 14:26

2010-09-06 15:05

Digerati

ohnobinki

normal

assigned

none

open

Ban/TKL Exception Blocks Clarification

Section 4.19: "The except ban block allows you to specify a user@host that will override a ban placed on a broader host..."

Section 4.20: "The except tkl block allows you to specify a user@host that will override a tkl ban placed on a broader host."

I suggest that section 4.19 be updated to be more clear on the purpose of this block. From what I understand, except ban overrides ban blocks in unrealircd.conf, and except tkl overrides tkl bans. It should be made clear that the except ban overrides blocks like the ban version, real name, etc. blocks.

Digerati

2005-05-25 14:36

According to aquanight in #unreal-support:

(14:07:24) (@aquanight) Digerati: except ban also affects bans via /kline
(14:07:37) (@aquanight) and /zline

If this is true (which I assume it is), this definately needs to be explained more clearly in the docs, and the specific differences between except ban and except tkl need to be distinguished.

aquanight

2005-05-25 23:29

I think it can be basically explained like this:

except tkl is exception from any (or all) of: gline, qline (ban nick {} or tkl, interestingly enough (no unreal does not have a builtin way to add tkl local qlines)), gqline (or sqline if you prefer), shun, gzline.

except ban is exception from all of: kline, zline (ban user/ip {} or tkl).

There is no exempt from spamfilter (short of oper{}, although when the kline/zline/gline/gzline spamfilter actions are used the corresponding except blocks apply).

Yes, I think the docs should probably mention this all :P .

White_Magic

2005-06-06 08:16

so basically, add a ban exception block rather than a tkl with all the types :P

stskeeps

2007-04-27 06:42

Bump. Still an issue?

syzop

2010-07-14 17:38

I don't know if this has been documented already, but we fixed some stuff related to this in the source, see changelog. The docs must reflect the current behavior (both the stuff below, and the stuff in this bugreport above).

- except ban { } is now also effective against Z:lines. It already protected
when the user was connected, but not once he/she tried to reconnect, this
is now fixed. Reported several times, last by Stealth in 0003377.

3893

ircd

major

always

2010-02-28 17:35

2010-09-06 15:05

R-TypeEman

ohnobinki

normal

assigned

none

3.2.8

open

Firefox XPS IRC Attack

Unreal is vulnerable to the following attack:

http://encyclopediadramatica.com/Firefox_XPS_IRC_Attack [^]

syzop

2010-02-28 17:53

Is that the same as 0003862 ?
And does the suggested module therein help against this ?
(As you can see I was happy to do something about it, but got no feedback at all. If it's the same issue, that is.)

syzop

2010-02-28 18:09

Seems so. Thanks for the heads up.
I'll enhance my module a bit (it was just proof-of-concept) and make it more public ;)

EDIT: btw, it should be mentioned that enabling NOSPOOF protects against this attack. Well, the clients will take up unknown connections, of course...

R-TypeEman

2010-02-28 19:29

that module seems to do the trick

thanks

syzop

2010-02-28 19:36

Ok :)
I've posted it on the website / news section: http://forums.unrealircd.com/viewtopic.php?t=6458 [^]
I wasn't paying too much attention to generic IRC news for the past 6 weeks or so, and nobody informed me until now about this.. so thanks again.

syzop

2010-07-14 17:07

ohnobinki: what do you think, I have my free module and such, I feel like it can be quite important for ircds to have...
Shall I just throw it in the unreal tree?

Another question is, should I call it like m_<whatever>, and make it included in commands.so too? That way, each ircd will run it. If I don't then many won't use it.
Feels like a good idea..

ohnobinki

2010-07-16 01:24

I think the module should be accepted as official (and thus shipped with unrealircd-3.2.9).

I'm not sure if it's necessary to have it compiled into commands.so. 3.2.9 will have NOSPOOF enabled by default now -- perhaps that is enough. But, yes, I don't know why an IRCd wouldn't want to have this. (it doesn't look like my uncertainty here is of any help ;-) ).

syzop

2010-07-16 14:52

hehehe
ok, let's put it in then. and yeah link it in commands.
perhaps name it m_something too so loadmodule m_*.so will include them if someone doesn't use commands.so.

still, have to think about the default settings. some users reported an annoying amount of notices regarding bots (webspiders) going to their ircd. hmmmm.

3776

ircd

feature

N/A

2009-01-04 11:48

2010-09-06 11:07

syzop

normal

new

none

All

3.2.9

open

Unreal3.2.9 TODO

Parent bug of TODO's for 3.2.9.

Usual disclaimer:
* Some things here might not be done, many other things not mentioned here will be done.
* Please do not post any bugnotes here. Post bugnotes in the original bugreports instead. Understand, though, that mass-posting to every and each issue "this should be in next version" will not be appreciated either.
* There's no clear ETA regarding this release, and if any estimate is given at a later point, then understand that these are date/time ESTIMATES, and are rarely 100% correct.

syzop

2010-07-14 16:51

Ok, I'm going to compile a list of things that should/will be done in 3.2.9.
These will be the only issues that will be looked at. (note to my fellow developer ohnobinki: that means only these ones may be committed and the ones we already talked about).

While I may say here and there in a bug that it will be rescheduled for 3.2.10, I won't do that for all 200+ issues.. so if it's not on the list, you may assume it is not scheduled to be in 3.2.9.

I want to release a 3.2.9 someday, and it does not help when constantly new issues get added to the list and patches being committed which are dubious to do right before release.

I'd like to release 3.2.9 this Summer (northern hemisphere ;p), but don't ask for an exact date or month :).

Please give me a few days or so to compile the full list.

syzop

2010-07-14 17:58

Ok, I'm like 75% through the bugitems now.

Release Critical: 0003916 0003720 0003893 #2837 (last one is private)

I forgot to mention, any doc bugs (be it in the HTML, the tech docs, or helpop etc), you may commit freely :P. There's a closing window for them, to give translators some time to get everything synchronized, but that's to be decided at a later point, and not within a month I think... I'll post a note here when it happens.

syzop

2010-07-14 21:34

Ok, I've gone through all bugs now. Quite inspiring ideas you see again when you do that, but most of them are for next release or after that... ;p

syzop

2010-09-06 11:07

Are there any bugids I can offer to you binki?
0003893 0003358 0002535 0002973 come to my mind

I'll do 0003720 and 0001522 myself (in that order), and then move on to any remaining issues.
EDIT: I don't know how quickly I'll finish them, it'll be 'next weekend' again ;)

I wouldn't mind if you did 0003848 and/or 0003943 either, but since it's Windows-related... :p

It would be nice if we could finish our work this month (September), and then go into testing mode...

3953

ircd

minor

N/A

2010-08-31 05:12

2010-09-03 02:59

Nath

normal

confirmed

none

Linux/Windows

Ubuntu (Linux)

3.2.8

open

Oper Idle times.

After reading through the m_whois.c file, I cam across a comment which didn't really apply to what the code was actually doing. The comment in question:

/*
* Fix /whois to not show idle times of
* global opers to anyone except another
* global oper or services.
* -CodeM/Barubary
*/

The code didn't appear to actually do that at all. So I decided to patch a usermode that opers can set, to hide their idle time if they so wish.

I have chose the usermode +I. For 2 reasons:

"I" can easily relate it "IDLE" and so seems practical to use.

"I" also can redeem itself as a sensible umode, and could potentially cause hassle for any more +I invisible hacks out there.

I have uploaded my patch, any constructive criticism is welcome. :)

hidle.patch (2 KB) 2010-08-31 05:12
unreal-3953-hidle-r1.patch (3 KB) 2010-09-02 22:10

ohnobinki

2010-08-31 22:14

In the diff in umodes.c, I suggest to try to fit in to the surrounding convention of 0L instead of 0l.

I don't understand why you're adding minus signs in the middle of m_whois.c and gcc doesn't either:
gcc -I../include -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING \
-o m_whois.so m_whois.c
m_whois.c: In function 'm_whois':
m_whois.c:332: error: wrong type argument to unary minus
make[2]: *** [m_whois.so] Error 1

In the comment about ``Umode I'', howabout ``Umode +I''? The + is a visual aid to me, not sure about others ;-). And prepend ``Nath'' with a `-' :-p

And I personally prefer simpler logic:
!((acptr->umodes & UMODE_HIDLE) && !IsAnOper(sptr))
could become the following perhaps?
(IsAnOper(sptr) || !(acptr->umodes & UMODE_HIDLE))

Stealth

2010-09-02 21:55

This is definitely a good idea, and I do agree with needing a little bit of cleanup to ensure that it is both functional and bettering the source.

ohnobinki

2010-09-02 22:23

unreal-3953-hidle-r1.patch: Fixes the things I addressed, compiles, and appears to work.

On a separate note, the m_whois.c lines that this patch modifies happens to be the line that causes user idle times to only show up if the WHOISee and the WHOISer are both on the same server. I.e., this ``MyConnect(acptr)'' check. Is this intended or should I open another bug to enable idle times to be checked from different servers?

Stealth

2010-09-03 02:59

Not showing remote idle times is intentional behavior (as most IRCds do this). To see remote idle times, you need to send "WHOIS <nick> <nick>". This might be addressed somewhere else in the source, as a server-server WHOIS is different than client-server.

3943

ircd

major

unable to reproduce

2010-08-13 11:07

2010-08-27 18:37

syzop

normal

feedback

none

Any

Windows

???

3.2.8

open

loadmodule permission denied errors on windows

It seems we frequently get users with 'Permission denied' problems in the support channel, and sometimes on the forums. However, there has never been a bugreport about it.

I wonder what's causing these errors, and if we can do something about it to prevent them... either in the installer or in Unreal.

It seems to happen more often than before, when I thought it was just someone incorrectly CACLS'ing or whatever their c:\program files, it seems to be a more general issue now...

I've never experienced the issue myself (XP), so any advice on how to reproduce it would be nice. Stealth, or anyone else? :P

It's not my idea to add issues this late for release, but if this could be fixed for 3.2.9 it would be nice, it seems like a real issue.. but I don't know how big it is or how easy or hard to fix...

Bock

2010-08-24 22:48

Unreal installer want admin rights for setup.
http://a.imageshack.us/img26/499/unrealwarn01.png [^]

Cannot run makecert.bat after install under user
http://a.imageshack.us/img90/3699/unrealwarn04.png [^]

Only if I give admin rights for me through Properties - Security to whole folder Unreal 3.2 it give to me write/read files and run unreal just starting wircd.exe

If I check "install as service", service is installed, but makecert.bat have the same problem. I need to open "cmd" as admin and start makecert.bat in Unreal3.2 dir.

I don't see loadmodule error in my Win 7 (x64).

KnopeX

2010-08-27 18:37

Since i have UnrealIRCd on Win7 i didn't notice a error when i loaded a 3rd party module or something else...

3922

ircd

feature

N/A

2010-07-12 10:51

2010-08-27 06:22

warg

normal

new

none

open

badwords exemption

The ability to exempt groups of people from the badwords filter would be neat.

# example:

set {
    # exempts +%@&~ from badwords
    badwords-exempt "+";

    # exempts %@&~ from badwords
    badwords-exempt "%";

    # exempts @&~ from badwords
    badwords-exempt "@";

    # exempts &~ from badwords
    badwords-exempt "&";

    # exempts ~ from badwords
    badwords-exempt "~";
};

ohnobinki

2010-08-26 04:36

What's the point of having badwords enabled at all if channel ops are going to break them?

warg

2010-08-27 06:22

last i checked it wasn't up to us to decide what the point of anything is :P but i agree, but i still think the feature would be useful in special cases, and if for specific channels, not server-wide.

3157

ircd

minor

always

2006-12-20 21:08

2010-08-26 05:23

vonitsanet

normal

acknowledged

RC3

none

3.2.6

open

More descriptive SSL error messages (underlying syscall error, etc)

When a connection between 2 connected servers (both rc3) with ssl + zib was lost i was seen this AND ONLY this without the junk snomask:

-FBSD6.unrealircd.testnet- Lost connection to WinXPPro.nonSSL.unrealircd.testnet[75.75.21.39]: SSL_read(): Underlying syscall error

vonitsanet +iowghaAsxNzG
Server notice mask (+kcfFvGqso)

unreal-3157-ssl-errno-condense.patch (6 KB) 2010-08-26 05:03
unreal-3157-ssl-errno-condense-r1.patch (7 KB) 2010-08-26 05:15

Bricker

2006-12-20 21:11

I got this error on my side of the netsplit

>[Dec 20 2006 21:29:10] Lost connection to FBSD6.unrealircd.testnet[72.20.15.245]: SSL_read(): Underlying socket operation returned zero

Bock

2006-12-21 01:22

and? /me don't see bug in this case - error of OpenSSL is difficult to see ;]

I see:
-win2003.unrealircd.testnet- *** LocOps -- Received SQUIT FBSD6.unrealircd.testnet from Bock|work[193.232.250.240] (@test!)

in other side:
-FBSD6.unrealircd.testnet- Lost connection to win2003.unrealircd.testnet[195.222.64.143]: SSL_read(): Underlying socket operation returned zero

tcp-kill:
-win2003.unrealircd.testnet- Lost connection to FBSD6.unrealircd.testnet[72.20.15.245]: SSL_read(): Underlying syscall error
-FBSD6.unrealircd.testnet- Lost connection to win2003.unrealircd.testnet[195.222.64.143]: SSL_read(): Underlying syscall error

syzop

2006-12-21 07:40

So ehm.. it gives an error? good then...

I don't understand.. what's the bug? :P

Bock

2006-12-21 07:59

/me don't see bug too :]

syzop

2006-12-21 08:54

or do you mean a better error *description* perhaps? yeah there's still room for improvement there.

basically what I fixed was that at least an error message is *shown* ;). Previously you could have seen no error at all (except with junk snomask), which was.. not good :P.

Bricker

2006-12-21 10:25

yeah, the description to me looks fucked up

syzop

2006-12-21 17:54

I've changed the title to "More descriptive SSL error messages (underlying syscall error, etc)" and will add it as a child to 3.2.7.

If this was an incorrect assumption (see also previous comments), then let me know.

Thanks.

vonitsanet

2006-12-21 19:44

"More descriptive SSL error messages"
Yep ;)

ohnobinki

2010-08-26 05:08

unreal-3157-ssl-errno-condense.patch: This was originally written to get rid of code duplication between fatal_ssl_error() and ssl_error_str(). As a side-affect, calls to fatal_ssl_error() now get errno passed along. Unfortunately, it seems that even this isn't providing too much useful information:

:test.ohnopub.net NOTICE a :*** Notice -- Client connecting on port 6338: b (ohnobinki@localhost) [clients] [secure AES256-SHA]
:test.ohnopub.net NOTICE a :Exiting ssl client b[ohnobinki@127.0.0.1.36116]: SSL_read(): Underlying syscall error [Success]
:test.ohnopub.net NOTICE a :*** Notice -- Client exiting: b (ohnobinki@localhost) [Input/output error]

Reminds me of the ``Success'' socket error that clients quit with when not using SSL. I'm not too creative, maybe I could've simulated some more catastrophic disconnection which would display something other than ``Success''... or maybe errno is being trampled on before I store a copy of it. Oh, likely that Debug() function calls vsprintf...

ohnobinki

2010-08-26 05:23

unreal-3157-ssl-errno-condense-r1.patch: This version supposedly saves errno before the Debug() call for SSL_read() and SSL_write() but I still don't get anything other than ``Success''. I guess this would potentially be more reliable... if it helps at all. I'm not sure how to generate an error other than ``success''.

3920

documentation

minor

always

2010-07-12 09:16

2010-08-26 04:42

warg

Stealth

normal

assigned

none

open

http://forums.unrealircd.com/viewtopic.php?f=3&t=353 [^]

http://forums.unrealircd.com/viewtopic.php?f=3&t=353 [^]

This should be updated, appended, or in some way refer to curlinstall

Cookies to ErikMouse

3921

ircd

feature

N/A

2010-07-12 10:46

2010-08-26 04:37

warg

normal

new

none

open

auto-join delay

An option to set a delay would be great for auto-join and oper-auto-join. Perhaps even an override, to allow an auto-join to a channel whose modes normally wouldn't permit it.

# example:

set {
    auto-join "#chan1,#chan2";
    auto-join-delay 1s;
    auto-join-override yes;
};

# or

set {
    auto-join {
        channels "#chan1,#chan2";
        delay 1s;
        override yes;
    };
};

ohnobinki

2010-08-26 04:37

Why is a delay needed?

2406

ircd

feature

N/A

2005-03-07 13:54

2010-08-25 15:32

Ron2K

normal

acknowledged

none

open

[Feature Request] /ELINE - exceptions for /GLINE

This is a request for an /ELINE command; it would place /GLINE exceptions (much like channel mode +e can override channel mode +b).

(Feel free to change the name /ELINE if you don't like it.)

Having such a command would allow GLINE exceptions to be set on the fly (currently, one has to add a ban exceptions block and rehash, which could be impractible in some situations). The command should take the same parameters and have the same syntax as the /GLINE command.

ELINEs could also be set to expire after a set time period, much like GLINEs.

Additionally, services packages should be able to take advantage of this feature (IRCServices would be able to do so if the EnableExclude option was enabled). Currently, IRCServices (and probably other services packages as well) do not set GLINEs if autokill exceptions are enabled, due to the lack of this feature, and instead fall back to issuing a /KILL for users that match autokill masks. This causes more traffic on the network (as well as the possibility that an autokilled user will get a message in before the /KILL is sent if the network is laggy enough).

I thought of this after reading a forum post by Zell; and therefore think that he should be co-credited with this should it be implemented. (Reference: http://www.phpmemx.net/~unrealir/forums/viewtopic.php?t=1592) [^]

Hopefully I've submitted all required information for this request. If there's anything that you think that I've left out, please let me know.

Zell

2005-03-07 15:45

Righty-o. Coders of Unreal: should this feature be implemented, a module for Anope will be created forthwith. The closer the code is to the m_tkl code, the easier it will be for Services packages to implement the feature in services.

I (and anyone else who wants to) will make a module for anope upon completion of this feature.
Other services coders, now is your time to be ready for this feature.

vonitsanet

2005-03-09 03:25

I will be very happy if this was added sometime:P
We need many times akill exceptions but we cant enable it coz ircservices does not add glines..

medice

2005-03-09 03:50

why do you use akills, since unreal supports gline which is imo easier to handle

vonitsanet

2005-03-09 06:41

medice this is not the point of this thing.
I said IF i use the akill exception feature for ircservices (and other services packages) and add an akill... services does not add glines because unrealircd does is not supporting glines exceptions (ELINES).
So servces can't manage exceptions with any other way..
They just issue /kill for the akills and allows the exceptions to pass.

Knippy

2005-04-03 21:29

I like this idea

Ron2K

2006-01-20 12:59

Syzop/codemaster: any word on this one?

(Yeah, I know, I should have followed up on this a LOT earlier, but my computer has been up the creek without a paddle for the last few months. BTW: I'm not expecting this to go into 3.2.x)

Zell

2006-01-20 15:29

Time for my two cents again =)

I still think the ELINE is a good command addition. Some servers/ircds already support exemptions... anyone remember AKILLEX/RAKILLEX ? Bingo =)

$0.02 deposited to Bugs forum. :-P

JasonTik

2006-01-20 19:47

I have an issue with this command. What does it exempt you from? gline? ok. how about gzline, shun, kline, zline, and other things like that. will it override config bans?

Whatever you say it will or wont do, I'm a user who wants it the other way. (So really, this is impractical unless we add another field, which breaks TKL compatibility.)

Ron2K

2006-01-22 02:13

Which is why, in my opinion, it should only be added (if at all) when 3.3 gets developed.

Now let's see... it would only affect glines, seeing as that's the only thing that you can have exceptions for in the conf file (EDIT: OK, just opened up the conf file and I'm horribly wrong, but seeing as services programs will probably only support gline exceptions (eg ircservices), let's keep it as gline exceptions only. Feel free to disagree with me here if you want.) I'm not sure whether or not this should override conf bans and I'm prepared to listen to both sides of that argument.

Zell

2006-01-22 16:37

m, maybe.

As it stands, lets take an example of the opposite.
Suppose you have a config exemption for kline on NiceGuy@*.rr.com
Suppose you /kline *@*.rr.com 0 :Bug off
Mr. NiceGuy does not get klined (the new command issued did not override the config)

So in that sense, the ELINE command shouldnt override config bans...

But on the other side, if you have a nasty config ban (that for some reason is wide but necessary (*.aol.com, anyone?)), then you can on-the-fly exempt specific users.. (StarChat does this with their AOL Registration script on their website)

Ron2K

2006-01-26 12:12

Zell, you make a valid point. What I'll do is take a look at InspIRCd (if I can get it to compile on Cygwin) and see how they implement it. They have /ELINE, if I remember correctly.

vonitsanet

2006-01-28 16:31

Is this on TODO for 3.2.4 or is something for the 3.3.x ?

Stealth

2006-01-28 20:55

If this already is not in 3.2.4, it won't be in it... Maybe next version

Ron2K

2006-02-23 11:25

OK, I haven't been able to get InspIRCd working (I'm probably doing something stupid) - but I've been thinking about the whole overriding conf bans idea, and I think that Zell is right there - this shouldn't override them.

syzop

2006-02-23 15:00

Strange I never commented on this one, guess I only talked with codemastr about it (long ago).

I find this a nice feature, and I don't exclude the possibility that it will end up in 3.2* ;).

aquanight

2006-02-25 00:08

If it's going to exempt from gline only then whether or not it overrides conf bans is moot: G:Lines can't be set in the conf.

KnopeX

2010-08-25 10:12

You mean ELINE like except ban { } and/or except tkl { } ?
Nice idea BTW :)

Zell

2010-08-25 15:32

KnopeX: Yes, exactly.

Coders: Any word on this actually getting implemented?

3950

ircd

minor

have not tried

2010-08-25 06:43

2010-08-25 06:50

ohnobinki

normal

assigned

CVS

none

3.2.8

open

oper-up message uses vhost instead of realhost

because people are too lazy to file their own bug reports:

2010/08/25
22:35 -!- Josh [Josh@Clk-77AA73F3.ri.ri.cox.net] has joined #unreal-support
22:35 -!- mode/#unreal-support [+v Josh] by UnrealHelper
22:36 <+Josh> Hey, is there any way when a staff member opers up I can get the server notice to show the real host instead of the masked one?
22:40 <~Stealth> ermmm... the oper notifications always show the real host
22:41 <+Josh> It shows the failed oper attempt's real host, but not a successful oper.
22:44 <@Jobe> thats a bug iirc
22:44 -!- infidel [~ecc@Clk-E2BE66C1.membersrealm.com] has quit [Ping timeout]
22:45 <@Jobe> hmmm
22:45 <@Jobe> the failed attempts use sptr->sockhost but the success notices use GetHost(sptr)
22:45 <@Jobe> :/
22:47 <+Josh> So, I'll take it as there's nothing I can do about it atm?
22:49 <@Jobe> report it on the bug tracker
22:49 <@Jobe> its still present in the current CVS revision as far as I can see
22:50 <+Josh> Will-co
22:50 <~Stealth> maybe binki will fix
22:50 <@Jobe> Stealth, dont we have to rape him to get him to work though?
22:50 <@Jobe> well that or bribery

For logging purposes/automated parsing of the snomasked notice, it would seem to make sense for the realhost to be provided. I don't think there is any reason to preserve display of the vhost in the notice.

Example logs:

notices:
00:36 [ohnopub] !ohnopublishing.net a (ohnobinki@undisclosed-981307ED) [binki] is now a network administrator (N)
00:36 [ohnopub] !ohnopublishing.net a (ohnobinki@test.net) [binki] is now a network administrator (N)
00:39 [ohnopub] !ohnopublishing.net Failed OPER attempt by a (ohnobinki@localhost) using UID binki [FAILEDAUTH]

commands:
USER a b c d e f
NICK a
OPER binki <password>
SETHOST test.net
MODE a -o
OPER binki <password>
MODE a -o
OPER binki wrongpassword

Expected behavior: the successful oper-up message should give the same host as the failure message.

unreal-3950-oper-up-no-vhost.patch (2 KB) 2010-08-25 06:50

3949

ircd

text

have not tried

2010-08-25 06:25

2010-08-25 06:26

ohnobinki

normal

assigned

CVS

none

3.2.8

open

./ircd --help should output usage information.

Yes, I know that --help isn't actually a switch for unrealircd. But passing an invalid switch does cause the usage information to be printed out.

I am filing this bug because I had to make some non-text changes to better improve the usage output and thus it should be reviewed.

unreal-3949-more-usage.patch (3 KB) 2010-08-25 06:25

3948

ircd

minor

N/A

2010-08-24 19:09

Eman

normal

new

none

open

Drop webtv support

webtv aka msntv is effectively dead at this point. i suggest removing support for it from unreal.

from #unreal3-devel
[2010/08/24 - 1:04:08PM] <Erik> binki: i cant help but think that maybe its time to drop webtv support
[2010/08/24 - 1:04:43PM] <@binki> erik: help me by filing a bug asking for that :-D
[2010/08/24 - 1:04:52PM] <@binki> i.e., that's what I'd like to do too

3947

ircd

minor

always

2010-08-23 20:58

2010-08-24 18:49

KnopeX

ohnobinki

normal

resolved

3.2.8.1 and older

none

All platforms

Windows and all other

3.2.8

fixed

/msg IRC whois <nick>: <nick> is a Secure Connection

Hello,

I found a bug in /msg IRC whois <nick> function. Looks like this:

<IRC> Shichirobei is a Secure Connection <- 'using' is missing.

Thanks.

Regards,
KnopeX

Type /msg IRC whois <nick>
But only users using SSL connections.

ohnobinki

2010-08-24 18:49

- Fix /msg IRC WHOIS response for persons with secure connections. (0003947)

In CVS and will be in 3.2.9.

Thanks for the report. However, note that the /msg IRC WHOIS ``feature'' should not be relied upon. (hopefully it will disappear someday ;-)).

3945

installing

minor

have not tried

2010-08-16 03:01

2010-08-23 22:54

ohnobinki

normal

new

CVS

none

3.2.8

open

./Config should support --with-system-cares and --with-system-tre

Currently, ./configure will by default compile a bundled version of TRE and c-ares. There is the possibility that a user will not want to do that and knows that his copy of libtre or c-ares is reliable (e.x., this person uses a package manager for everything but unrealircd itself because he wants to compile special unreal modules).

I do not think that a user could reasonably be expected to find out about the --with-system-tre and --with-system-cares ./configure options. Perhaps two new questions can be added to ./Config -advanced?

I would like to get clearance on this before writing the patch ;-).

Bock

2010-08-20 13:33

I think it must be added to ./Config -advanced
We use debian and using system libs will be perfect.

ohnobinki

2010-08-20 14:19

> We use debian and using system libs will be perfect

Then you should probably start petitioning for debian to version bump their libc-ares2 package to >= 1.6.0 ( https://bugs.launchpad.net/debian/+source/c-ares/+bug/561942 [^] ) and ascertain that https://bugs.launchpad.net/ubuntu/+source/tre/+bug/561933 [^] isn't also a debian bug ;-). UnrealIRCd should work fine with c-ares-1.5, but its buildsystem and #error directives force you to use 1.6.0 or greater. UnrealIRCd depends on pkg-config files when compiling against a system-installed libtre or c-ares. Otherwise, you'll need to specify CARES_LIBS and CARES_CFLAGS manually, which is just annoying.

Bock

2010-08-20 14:43

you can see our "unoficcial" debs for unreal.
ftp://ftp.bynets.org/debian/ [^]
Libs present in depends. In /version from our servers:

15:36:29 -!- Unreal3.2.8. solo.bynets.org FhinXeOoZEmM3 [Linux solo 2.6.26-2-686 #1 SMP Wed May 12 21:56:10 UTC 2010 i686=2309]
15:36:29 !solo.bynets.org OpenSSL 0.9.8g 19 Oct 2007
15:36:29 !solo.bynets.org zlib 1.2.3.3
15:36:29 !solo.bynets.org libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18

or:

15:37:45 -!- Unreal3.2.8. irc.mgts.by FhinXeOoZEmM3 [Linux irc 2.6.26-2-vserver-amd64 #1 SMP Thu Nov 5 03:47:07 UTC 2009 x86_64=2309]
15:37:45 !irc.mgts.by OpenSSL 0.9.8c 05 Sep 2006
15:37:45 !irc.mgts.by zlib 1.2.3
15:37:45 !irc.mgts.by libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5

but: "/quote dns i" give and I think, what we use c-ares from unrealircd.
Maybe check version of c-ares in distro for enable/bisable "--with-system-cares"

15:41:25 -!- ****** DNS Configuration Information ******
15:41:25 -!- c-ares version: 1.6.0
15:41:25 -!- timeout: 3000
15:41:25 -!- tries: 2
15:41:25 -!- # of servers: 1
15:41:25 -!- server #1: 127.0.0.1
15:41:25 -!- ****** End of DNS Configuration Info ******

ohnobinki

2010-08-20 16:06

> Maybe check version of c-ares in distro for enable/bisable "--with-system-cares"

I'm having trouble understanding what you're saying ;-).

--with-system-cares (0003847) and --with-system-tre (0003842) already exist in CVS. This bug is a request to give these options more public by adding direct support for them into ./Config so that users know these options are available.

> you can see our "unoficcial" debs for unreal.

Cool. However, I don't use Ubuntu ;-). I just want you to push your distro's packagers and it seems more your role to do that than mine.

hrrm... I think I'm wrongly using the bug tracker as if it were the forums :-/.

Bock

2010-08-20 18:26

I'll check in Monday in debian/testing.

Bock

2010-08-23 08:23

compiled unreal with parameters:
./configure --enable-libcurl --with-showlistmodes --with-topicisnuhost --enable-nospoof --enable-ssl --with-shunnotices --enable-ziplinks --enable-prefixaq --with-listen=5 --with-dpath=/usr/local/src/Unreal3.2.9 --with-spath=/usr/local/src/Unreal3.2.9/src/ircd --with-nick-history=2000 --with-sendq=3000000 --with-bufferpool=18 --with-permissions=0660 --with-fd-setsize=1024 --enable-dynamic-linking --with-system-cares --with-system-tre

installed package: libc-ares-dev, libssl-dev, zlib1g-dev, libcurl4-openssl-dev | libcurl-dev, libtre-dev

./unreal start
Starting UnrealIRCd
_ _ _ ___________ _____ _
| | | | | |_ _| ___ \/ __ \ | |
| | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| |
| | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` |
| |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |
\___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|
                           v3.2.8.1
                     using TRE 0.8.0 (BSD)
                     using OpenSSL 0.9.8o 01 Jun 2010
                     using zlib 1.2.3.4
                     using libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6

* Loading IRCd configuration ..
* Configuration loaded without any problems ..
* Initializing SSL.
* Dynamic configuration initialized .. booting IRCd.
---------------------------------------------------------------------

Checked remote include (checking curl-config... yes
configure: WARNING: cURL seems compiled without c-ares support. Your IRCd will possibly stall when REHASHing!) - worked fine and rehashing so fast.

Do you needed ane config.log or something?
Debian version: squeeze (testing).

ohnobinki

2010-08-23 14:12

> Checked remote include (checking curl-config... yes
> configure: WARNING: cURL seems compiled without c-ares support. Your IRCd will possibly stall when REHASHing!) - worked fine and rehashing so fast.

This means that your system-installed libcurl should be rebuilt with c-ares support. See that the output of the following command on your machine looks different from mine:

ohnopublishing portage # pkg-config --variable supported_features libcurl
"SSL IPv6 libz AsynchDNS NTLM"

You're missing ``AsynchDNS''. See ``asynchonous name resolving'' under http://curl.haxx.se/docs/features.html [^]

> Do you needed ane config.log or something?

I'm not sure what you're asking :-/.

Bock

2010-08-23 15:05

pkg-config --variable supported_features libcurl
"SSL IPv6 libz IDN NTLM"

for what purposes need c-ares in curl? For downloading files?
I have in conf:
include "ftp://ftp.bynets.org/configs/unreal/badwords.all.conf"; [^]

and in tmp/ file present:
-rw------- 1 bock staff 1912 ??? 20 2006 EA2B302D.badwords.all.conf

After rehashing:
-rw------- 1 bock staff 1912 ??? 20 2006 38E31C42.badwords.all.conf

Ah, I understand. If ftp not avaliable, ircd not freeze, just continue working. In debian I didn't find package curl with c-ares.

ohnobinki

2010-08-23 15:13

> for what purposes need c-ares in curl? For downloading files?

For remote includes support.

> If ftp not avaliable, ircd not freeze, just continue working

Actually, if your DNS is down or slow and your curl doesn't support c-ares, it'll freeze.

> In debian I didn't find package curl with c-ares.

Time for you to file some bugs against debian? :-p

Bock

2010-08-23 15:47

16:46:44 -!- unrealircd.conf Rehashing
16:46:59 !belarusbank.local *** Notice -- Loading IRCd configuration ..
16:46:59 !belarusbank.local *** Notice -- [warning] unrealircd.conf:7: include: error downloading
'ftp://ftp.bynets.org/configs/unreal/badwords.all.conf': [^] Couldn't resolve host 'ftp.bynets.org' -- using cached version instead.
16:46:59 !belarusbank.local *** Notice -- Configuration loaded without any problems ..

True.. 15 seconds.

Bock

2010-08-23 22:54

Hm. This bug ONLY if dns working slow or not avaliable and oper do /rehash.
If dns configured correctly, all other errors (file not found, host not resolved, etc) - no this delay.
I think that not so many people rehashing their IRCd every 15 mins or so.. In case with --enable-libcurl give a warning, that system don't sypport asyns dns requests and maybe slow down on rehashing. On --with-system-cares just check for version (=> 1.6.0).

3705

ircd

minor

N/A

2008-06-18 20:59

2010-08-23 19:02

Stealth

normal

new

none

3.2.7

no change required

Review Gentoo Patches

We should check out the Gentoo patches to see if they were real 'security issues' or just the Gentoo people doing stupid stuff with our IRCd.

If the patches really do fix stuff, they should be applied.

cdf123

2008-06-27 16:05

Please take a look at this bug. I would be interested to know if the module copy before load is needed.

http://bugs.gentoo.org/show_bug.cgi?id=223835 [^]
Trusted Path Execution in the grsecurity patches breaks unrealircd by preventing any modules from loading. The /tmp/*.so module is owned by a non-root and non-tpe-trusted user and gets denied execution.

w00t

2008-07-02 14:57

It's most assuredly not required if the install process operates 'properly', which it currently doesn't

By that, I mean that using 'cp' and equivilants to move shared objects around breaks things, which this copy hack is aimed at bypassing - if instead of this, shared objects were installed into a lib/ directory (or whatever) inside Unreal's folder through `install' (1) instead of cp, the problems of overwriting shared objects while running would go away.

(We had this problem with InspIRCd a few years ago - I'm surprised nobody's found the solution yet..)

Though, I'm not sure what kind of a timeline you'd see on a fix, cdf123. Things have been a bit slow for a while here.

syzop

2008-08-04 08:26

If your question is why we are copying to a tmp directory (tmp/ inside of the Unreal directory of course, not /tmp.. that would be a horrible idea) then the answer is: because otherwise a new version of a module would not load. This is because Unreal does "SAFE" module reloading, meaning: when we rehash (reload a module) we don't close the old module handle (dlclose) and then open the new one (dlopen), no.. we KEEP the old one open and THEN open a new one and do some checks and if they pass the old one is closed. This makes sure that not something odd can happen between closing the old one and opening the new one(eg: out of fds, or.. well several possibilities).
In contrast to MANY other software, which does not do this... I hope inspircd is not one of them, anope is I think..
That's the only reason for hardlink and/or copy, it's to fool the dl loader which will otherwise NOT load the new module because it knows the old one is still in memory and THINKS it's the same (reference count...), even though it's not...

Oh and yes, I suppose it also helps against overwrites, such as someone compiling or copying things over, but that's just an extra bonus.

So, if you removed the copy-or-hardlink-before-load, then you just broke the upgrade-on-the-fly capability.

w00t

2008-08-04 08:59

Oh, I wasn't aware you tried to reload everything on a /rehash, we don't do that as it would be way, way too slow with the number of modules we have (and, as you've observed, because we don't have a /tmp copy).

Instead, on rehash, two lists are generated; modules which have been unloaded - as well as ones that have been loaded. Those two are processed, anything not on those lists isn't touched.

To 'upgrade on the fly', /reloadmodule m_blah.so or /unloadmodule and /reloadmodule are required.

Stealth

2009-07-24 01:21

Is this still an issue? Or did we determine this is entirely to do with Gentoo's ports?

syzop

2009-08-17 11:49

implementing this breaks things rather than solving anything :P.

ohnobinki

2010-08-23 19:02

May this be made compile-time configurable to support hardened systems? If someone is running Gentoo hardened and does a /rehash, there is no need to reload modules because none of them will have changed. Also, perhaps there is a more correct way to force libdl to reload a library.

3946

ircd

feature

always

2010-08-22 21:15

2010-08-23 07:12

tabrisnet

normal

confirmed

none

3.2.8

open

CS INVITE noisy due to ircd invite notice

Implemented a CS JOIN that calls CS INVITE (if user has access), so that a JOIN may always succeed (regardless of +i, +k, +b, etc). Unfortunately every time a user with access uses CS JOIN (NS AJOIN uses CS JOIN), an invite notice is sent to the channel. For some channels, this is considered annoying.

Can we add a SVSINVITE that doesn't do this, or make a configurable option to disable the notice?

unreal-3946-no-invite-channotice.patch (1 KB) 2010-08-23 07:11

ohnobinki

2010-08-23 05:11

I think that this has come up before, with the correct solution being use of some invite numeric instead of an invite notice.

ohnobinki

2010-08-23 07:11

unreal-3946-no-invite-channotice.patch: I think that this is the correct way to inform channel members (ops only) of channel invites.

3794

installing

minor

always

2009-01-14 22:51

2010-08-20 16:02

ohnobinki

normal

resolved

none

amd64

Gentoo

2.0

3.2.7

fixed

missing aclocal files

When I enter into the automake directory and run "autoreconf -vfi ..", the configure file is created. However, I get the following in the output of ./configure:

checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for uid_t in sys/types.h... yes
./configure: line 6052: unreal_CHECK_TYPE_SIZES: command not found
checking what kind of nonblocking sockets you have... O_NONBLOCK
checking whether x86_64-pc-linux-gnu-gcc needs -traditional... no
checking whether setpgrp takes no argument... yes

I found that this macro is defined inside of aclocal.m4, but running aclocal tries to regenerate aclocal.m4 and the definition of unreal_CHECK_TYPE_SIZES is not included in the .tar.gz.
I checked out the 3.2.8-rc1 .tar.gz file and found the same problem.

I am interested in being able to modify configure.in and completely regenerate all of the generated autoconf/automake/autowhatever files:-).
Thanks for any help.

ohnobinki

2009-01-15 02:54

another autoconf macro which isn't included in the tarballwell, :

checking for inflateEnd in -lz... (cached) yes
checking zlib in /usr... ok
./configure: line 10857: CHECK_LIBCURL: command not found
checking if FD_SETSIZE is large enough to allow 1024 file descriptors... yes
checking for TRE... yes
extracting c-ares resolver library

ohnobinki

2009-01-18 19:20

I'd like to extend this bug to be a request for all source files to be added to the tarballs/repository. I'm not sure where to find files like Makefile.am or configure.ac. Is there a place that they are published?
Providing these and related files as part of the tarball would aid people who want to hack the UnrealIRCD code.

Stealth

2009-01-18 21:25

It's not necessary for these files to be included in the tarball. If you would like them, you can get them from the CVS repository.

ohnobinki

2009-02-23 16:53

I can not find the CVS repository. I found the SVN repository and looked for such files (*.ac, *.am) , but none existed. Are there instructions somewhere for updating the autoconf/automake files?

ohnobinki

2009-03-04 00:38

I have finally realized that unrealircd doesn't use automake, so I guess the request for *.am files is incorrect. However, I still have difficulty running aclocal; autoconf because I have to rename aclocal.m4 to acinclude.m4 to get aclocal to see your macros.
I guess this bug is reduced to a request that you change the name of aclocal.m4 to acinclude.m4 :-).

ohnobinki

2010-08-20 16:02

with the restructuring of ./configure.ac and advent autoconf/m4 and ./autogen.sh, I think what I complained about in this bug is fix.

3329

ircd

minor

always

2007-05-11 00:44

2010-08-20 13:17

Bock

ohnobinki

normal

resolved

none

i386

all

3.2.6

fixed

Not unsetting all modes on /umode2 -o

I think then I deoper myself, usermode +s must be unset too.

from conf:
modes-on-oper "+wgs";
restrict-usermodes "skB";

on oper:
[08:38:27] ::: Mode change [+oghaAsNW] for user wx|wrk
[08:38:27] ::: Server notice mask (+kfjveGqSso)
[08:38:27] ::: You are now an IRC Operator
on umode2 -o:
[08:38:35] ::: Mode change [-oghaANW] for user wx|wrk
[08:38:35] ::: Server notice mask (+ks)

I think that on umode2 -o: must be : Mode change [-oghaAsNW] for user wx|wrk

unreal-3329-deoper-remove-snomask.patch (2 KB) 2010-08-19 05:39

aquanight

2007-05-11 09:41

Keep in mind +s is allowed for nonopers by default. However, if you've put s in restrict-usermodes, it really should indeed be removed (since it's effectively an "oper-only" mode). Same for all usermodes listed there. Dunno if that's what happens or not.

(edit: and I now notice you do indeed have it in restrict-usermodes, so...)

Stealth

2007-05-11 14:20

perhaps on deoper have Unreal check for restricted-usermodes NOT in set-modes on connect, and remove those

Bock

2007-05-11 15:36

+1 to Bugz

syzop

2010-07-14 17:34

Sounds like something quite easy to fix, check if s in there, and remove s.

Is a slight security issue (ok, that's maybe a bit exaggerated) if this won't get fixed --> 3.2.9.

vonitsanet

2010-07-18 16:35

Correct me if i'm wrong..

Is this command supposed to be used by clients?
I remember someone who wrote (years ago, so i don't remember details) that umode2 is for another purpose.

syzop

2010-07-18 17:12

Yea I don't care too much about umode2, but.. I'm assuming the same issue exists with MODE $nick -o as well.

ohnobinki

2010-08-19 04:38

OK, so would the fix be to remove s if and only if both of the following are satisfied?
- s is in restrict-usermodes
- s is in modes-on-oper

ohnobinki

2010-08-19 05:02

oh,and:
- s is not in modes-on-connect

ohnobinki

2010-08-19 05:27

Seems that whether or not modes-on-oper contains `s' has no bearing on whether or not opering up will give the oper a snomask, thus we are left with:
- s is in restrict-usermodes
- s is not in modes-on-connect

Bock

2010-08-19 07:35

In our config:
    modes-on-connect "+wi";
    modes-on-oper "+wgs";
    restrict-usermodes "skB";

syzop

2010-08-19 17:26

ohnobinki: Yup, exactly.

ohnobinki

2010-08-20 13:16

Interpreting that as a ``go ahead and commit'' ;-).

- Remove snomasks upon deopering when it seems like the user shouldn't have snomasks. (0003329)

3053

ircd

tweak

N/A

2006-09-04 11:45

2010-08-20 13:11

Stealth

ohnobinki

normal

resolved

none

3.2.6

fixed

Warning when running as root

If Unreal is started as root, I think it would be great to have it print a warning and have the user enter a confirmation. Maybe have the user say it is OK once like X-Chat does.

Such as:

WARNING: Running Unreal as root is bad!
Start anyway? (yes/no):

unreal-3053-warn-root.patch (2 KB) 2010-08-20 05:53

codemastr

2006-09-04 12:48

X-Chat is a client program. Unreal is a daemon. A daemon shouldn't ask questions like that. For example, consider having a script that starts Unreal. It will now hang waiting for someone to type "y". I agree, you shouldn't run Unreal as root, but I think this is a bad way to solve the problem. The more questions an IRCd has to ask, the more difficult it is to automate.

Stealth

2006-09-04 14:11

That's why it only asks once... It can store the yes result in the tune file or smth

pinstrate

2006-09-04 15:47

I promise I'll write a patch to remove this stuff from the core if it will be added.

Behave like all other ircds - just warn but nothing more!

aquanight

2006-09-04 16:37

Also there are reasons that it may be necessary for unreal to boot as root, chroot and setuid/setgid to name a few (though this then gets to crazy interactions with /rehash, /restart and such). Also the pedants who want to use the IANA IRC port (194 I think?) that's in the privileged range have to start unreal as root (and setuid probably doesn't work in that case).

Look at most of the other common daemons (syslog, sshd, httpd, ftpd, ntpd, cron, etc). How many of them ask "Are you sure you want to start this daemon as root?" on /dev/console first time you start your system? That would be bad for a headless system.

syzop

2006-09-04 16:57

Warning? Sure. But not if IRC_UID is defined and > 0.
Prompt or anything else? No.

djGrrr

2006-09-07 21:27

IANA IRC port (194 I think?) <-- technically you don't need to start as root for that, as you can setup a firewall rule to say, forward port 194 (a virtual forward to the same box) to something higher like 6667.

Most if not all firewall packages for *nix and *bsd support this in some way shape or form, and its actually quite useful in situations like that :)

pinstrate

2006-09-08 01:48

stupid idea actually..

You flush your fw and everyone is connection reset by peer or ping timeout.

djGrrr

2006-09-08 08:34

And for what reason would you ever flush your firewall ?
This wouldn't be for someone who doesn't know what they are doing....
If you have it setup correctly, flushing your firewall doesn't disconnect existing connections, it would just deny new connections to the virtual port.

*most* people aren't exactly in the habbit of flushing their firewall if its going to cause disconnections....

syzop

2010-07-14 21:01

I think we can resurrect this idea again ;)

See my (2006) comment: add a (clear) warning, but don't warn if IRC_UID (or IRC_USER nowadays?) is in use (coz it will setuid...).

ohnobinki

2010-08-20 05:53

unreal-3053-warn-root.patch: Warns users if they are starting UnrealIRCd as root and seteuid() is not enabled. Tested with IRC_USER and IRC_GROUP set and unset, seems to work.

syzop

2010-08-20 11:09

Looks good.
Though, you might want to mention something about setting IRC_USER in include/config.h in the error message.
Basically, give a suggestion of what the user should do: 'Either start the IRCd as another user than root, or properly set IRC_USER in include/config.h'.. something like that...

ohnobinki

2010-08-20 13:11

OK, the text has been lengthened to include those instructions and committed.

- Warn users against running UnrealIRCd as root without setting IRC_USER. (0003053 reported by Stealth)

3189

ircd

minor

always

2007-01-04 21:17

2010-08-19 03:06

TommyTheKid

ohnobinki

normal

resolved

none

ppc

Mac OSX

10.4.8

3.2.6

fixed

improper use of mode_t for DEFAULT_PERMISSIONS in chmod and open operations

For some reason, on the mac, ./include/setup.h has a line:

#define DEFAULT_PERMISSIONS 600

(its missing the leading zero)

.. I am not sure *why* that happens, or whether it affects more than just OSX 10.4, but it lead to me discovering that putting 0600 is not really a proper use of "mode_t" for chmod/open operations.

As per the following man page...

[man 2 chmod]
CHMOD(2) BSD System Calls Manual CHMOD(2)

NAME
     chmod, fchmod -- change mode of file

SYNOPSIS
     #include <sys/types.h>
     #include <sys/stat.h>

     int
     chmod(const char *path, mode_t mode);

     int
     fchmod(int fd, mode_t mode);

DESCRIPTION
     The function chmod() sets the file permission bits of the file specified
     by the pathname path to mode. Fchmod() sets the permission bits of the
     specified file descriptor fd. Chmod() verifies that the process owner
     (user) either owns the file specified by path (or fd), or is the super-
     user. A mode is created from or'd permission bit masks defined in
     <sys/stat.h>:
           #define S_IRWXU 0000700 /* RWX mask for owner */
           #define S_IRUSR 0000400 /* R for owner */
           #define S_IWUSR 0000200 /* W for owner */
           #define S_IXUSR 0000100 /* X for owner */

           #define S_IRWXG 0000070 /* RWX mask for group */
           #define S_IRGRP 0000040 /* R for group */
           #define S_IWGRP 0000020 /* W for group */
           #define S_IXGRP 0000010 /* X for group */

           #define S_IRWXO 0000007 /* RWX mask for other */
           #define S_IROTH 0000004 /* R for other */
           #define S_IWOTH 0000002 /* W for other */
           #define S_IXOTH 0000001 /* X for other */

           #define S_ISUID 0004000 /* set user id on execution */
           #define S_ISGID 0002000 /* set group id on execution */
           #define S_ISVTX 0001000 /* save swapped text even after use */
[snip]

(this was from Mac OSX, but Linux, Solaris and others have extremely similar information)

... DEFAULT_PERMISSIONS should be defined as:

#define DEFAULT_PERMISSIONS (S_IRUSR|S_IWUSR)

** this might even allow the "DEFAULT_PERMISSIONS" to work on other OS's like "d0ze" ?

on OSX? maybe others?

run ./Confg
(select defaults)
.. verify as the system runs ./configure, there is a --with-permissions=0600

.. somewhere during ./configure, the leading zero gets lost (at least on Mac OSX)

look at ./include/setup.h, if DEFAULT_PERMISSIONS is "600" and not "0600" ircd will not start, cause it will chmod your unrealircd.conf file to look like:

---x-wx--T 1 ircdev ircdev 3665 Jan 4 18:17 unrealircd.conf

.. which is not readable.

---x-wx--T -> 1130
... curiously if you do printf("%o\n", 600); you get 1130 :)

configure.patch (0 KB) 2007-01-05 12:10

TommyTheKid

2007-01-04 21:20

ugh, for what its worth, you can specify "0" for the default permissions to work around this, or modify ./include/setup.h to add the leading zero to the DEFAULT_PERMISSIONS.. or if you desire, properly define it (S_IRUSR|S_IWUSR)

~tommy

stskeeps

2007-01-05 04:09

0600 points out it's octal in C - i noticed this some weeks ago myself.

Try printf("%i %i\n", 0600, 600)

TommyTheKid

2007-01-05 11:12

For those that have not figured this out, and I meant to paste this output above... HERE is what it looks like when this bug manifests itself.

$ ./unreal start
Starting UnrealIRCd
_ _ _ ___________ _____ _
| | | | | |_ _| ___ \/ __ \ | |
| | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| |
| | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` |
| |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |
\___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|
                           v3.2.6
                     using TRE 0.7.2 (GPL)
                     using OpenSSL 0.9.7l 28 Sep 2006

* Loading IRCd configuration ..
[error] Couldn't open "unrealircd.conf": Permission denied
[error] Could not load config file unrealircd.conf
[error] IRCd configuration failed to load
Possible error encountered (IRCd seemingly not started)
=====================================================
Check above for possible errors, and this output of
ircd.log. If you cannot solve the problem, read
Unreal.nfo on where to get support
=====================================================
[Thu Jan 4 19:34:23 2007] - TIME SYNCH: timeserver=1167968063, our=1167968063, offset = 0 [old offset: 0]

$ ls -l unrealircd.conf
---x-wx--T 1 ircdev ircdev 3665 Jan 5 09:05 unrealircd.conf

Again, this is due to the (shell|autoconf|somethingelse?) treating the --with-permissions=0600 like a regular (decimal) number and "simplifying" it to 600 on assignment to the variable $with-permissions (which for some reason is assigned to $withval) and added to the .h file incorrectly during the configure script.

http://www.google.com/search?q=600+in+octal [^]
600 = 0o1130

~tommy

TommyTheKid

2007-01-05 12:14

I have included a temporary patch (configure.patch) that changes one line in ./configure

(slightly modified to make more sense and protect the innocent)

[10:53:50] <TommyTheKid> ac_optarg=`expr "x$ac_option" : 'x[^=]*=$.*$'` <-- there is where it gets botched
[10:54:16] <TommyTheKid> mini:~ ircdev$ ac_optarg=`expr "x$ac_option" : 'x[^=]*=$.*$'`
[10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_optarg
[10:54:16] <TommyTheKid> 600
[10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_option
[10:54:16] <TommyTheKid> --with-permissions=0600

[10:54:48] <satmd> it's the expr in there

[10:56:24] <satmd> how about echo "x$ac_option" | sed 's,x[^=]*=$.*$,\1,' ?

[10:57:11] <satmd> TommyTheKid's expr isn't broken
[10:57:18] <satmd> it just handles numbers as numbers
[10:57:25] <satmd> - stripping leading zeros
[10:57:29] <TommyTheKid> satmd: it does work (come up with 0600)
[10:57:31] <satmd> :)
[10:58:07] <satmd> would you please submit it as a bug and include it in patch format?

*** This resolves the "issue" that I am experiencing, and should probably work OK for most POSIX complaint machines, but at some point someone should look into the proper use of chmod(2)

~tommy

syzop

2007-01-06 15:51

Yes this is an OS X bug. I think I heard about it before (don't know if it was ever reported, though).

syzop

2010-07-14 17:53

We should fix this in 3.2.9, or was this already addressed? There were some mac fixed in the past few years... might even be fixed before 3.2.8?
Note that part of the bug is the missing 0 (somehow), and not something like a bad syscall/function.

ohnobinki

2010-07-14 18:42

I just tested CVS and 3.2.8.1 on Mac OSX 10.5.8 and this issue still exists. From satmd's patch, I wonder if this is an autoconf bug.

ohnobinki

2010-08-17 19:22

I know that satmd wrote essentially the following somewhere, but I want to record it for myself here. The problem is a bug in Mac OSX's expr(1) program:

peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*$.*$'
=0660
peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*=$.*$'
660

ohnobinki

2010-08-19 03:06

I filed a bug against Mac OSX, but I think the below solution is better for two reasons.

First, it should stop this problem from happening on Mac OSX -- including old versions (even if a new OS X actually was fixed by Apple...). Secondly, it will act like chmod(1) which users are more used to using (where chmod 600 myfile is the same as chmod 0600 myfile). I'm quite sure that an extra zero in front of the value (i.e., 0600 now becomes 00600 on Linux or machines with non-buggy expr(1) programs) can't possibly cause anyone harm ;-).

- Prepend a `0' to the begining of --with-permission, working around a Mac OS X bug and hiding the fact that chmod()'s params are octal from users. (0003189)

3944

ircd

minor

always

2010-08-15 20:02

2010-08-16 11:33

Jobe1986

syzop

normal

resolved

none

x86

FreeBSD

7.0

3.2.8

fixed

FreeBSD, IPv6 build, IPv4 listen blocks and *:port listen blocks

OK, today I found a few issues with using UnrealIRCd 3.2.8.1 on FreeBSD 7.0 with IPv6 support enabled. Those issues are:
A) "listen *:6667;" only listens on IPv6 IP's (http://bugs.unrealircd.org/view.php?id=2741 [^] suggests a solution that requires root which isnt an option for everyone)
B) A listen block specifying an IPv4 IP (both "1.2.3.4:6667" and "[::ffff:1.2.3.4]:6667" forms) fails with an error suggesting another solution, once again requiring root.

So having found a solution that does not require root, I have attached a .diff with a solution to BOTH issues.

unreal-ipv6-bsd.diff (0 KB) 2010-08-15 20:02

warg

2010-08-15 20:05

I like this ++

syzop

2010-08-15 21:09

This is already in latest CVS ;)

#if defined(INET6) && defined(IPV6_V6ONLY)
        /* We deal with both IPv4 and IPv6 in one (listen) socket.
         * This used to be on by default, but FreeBSD, and much later Linux
         * sometimes as well, seem to default it to IPv6 only ('1').
         * We now have this new fancy option to turn it off in Unreal,
         * instead of requiring our users to sysctl.
         */
        opt = 0;
        if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (OPT_TYPE *)&opt,
            sizeof(opt)) < 0)
                        report_error("setsockopt(IPV6_V6ONLY) %s:%s", cptr);
#endif

Anyway, I never got an opportunity to test it. But it works?

ohnobinki

2010-08-15 22:08

This code is already in CVS.

One note I'd like to make, however, is that on certain installations, setsockopt() _does_ return nonzero and spits a bunch of ``setsockopt(IPV6_V6ONLY)'' errors into ircd.log when it seems that there is no need to report such an error. (i.e., the setsockopt() call fails even though the IPv4 over IPv6 stuff is working find).

ohnobinki

2010-08-15 22:11

Ugh, I should'nt've touched this bug, I've only messed up its state :-/.

Jobe1986

2010-08-15 22:26

Yes this does work on FreeBSD 7.0. But it is worth noting that this will not work on Windows due to Windows lack of dual stack support. So in case you haven't already (your paste didn't mention it) you should make sure this fix only applies to non-windows builds at the very least.

As for already being in CVS, I suppose I really should have checked first. :P

syzop

2010-08-16 11:33

Ok, glad to hear it actually works :)

Jobe: as for windows, we don't support IPv6 on windows, see 0000008

ohnobinki: good point, now got rid of any possible warning in CVS .868:
- Get rid of any setsockopt(IPV6_V6ONLY) errors in ircd.log (0003944).

2620

installing

tweak

N/A

2005-08-15 07:05

2010-08-16 04:30

pinstrate

ohnobinki

normal

resolved

none

unix-like

all OSes

3.2.4

fixed

copying ircdcron/ircdchk to the destination dir with `make install`

I think that it would be a good idea if the whole ircdcron or at least ircdcron/ircdchk file would be copied to the destination directory when make install'ing.
this would:
*ensure that the script will still check (if added to cron, of course) if ircd is alive even if something happens with source directory (eg. gets removed, overwritten and so on)
*save some manual copy'ing :)

Let's say I often like to dowload cvs version and install it.. here are the steps I do:

rm -rf /home/my/unreal-cvs-dir
wget the_latest_cvs
./Config and make
then rm -rf /home/my/irc.server.net dir
make install
*then* each time I have manually copy the ircdcron dir to my /home/my/irc.server.net directory..

It would be nice if Unreal would do it automatically :)

pinstrate

2005-08-15 07:06

Sorry, forgot to mention about copying my *.conf files back to the server's directory, but that is not a big issue I think.

syzop

2010-07-14 21:04

We should do this (copying on make install).

I did not really verify if this was already fixed, though... a quick grep suggests it isn't.

ohnobinki

2010-08-16 04:30

- Install ircdcron scripts. (0002620)
- Autogenerate ircdcron/ircd.cron based on ./configure settings.

3916

ircd

minor

N/A

2010-07-05 13:22

2010-08-16 04:13

syzop

ohnobinki

normal

resolved

none

fixed

upgrade TRE

upgrade tre to 0.8.0 and do much testing...

syzop

2010-08-08 20:25

unassigned (for now). I'm fine if you'd like to do this, binki...

ohnobinki

2010-08-16 02:57

I've already done the hack I mentioned above for c-ares, so I might as well do the same for libtre.

ohnobinki

2010-08-16 04:13

- Upgrade to tre-0.8.0, adding hack similar to the one for c-ares to ensure that the bundled tre is compiled against even when a system libtre is installed. (0003916)

Concerning the much testing: I don't yet have any methodologies to stress-test the regexp-reliant portions of unrealircd (such as spamfilter). I think it's best to just commit this now and hope that possible bugs show up for CVS users. I know that I've had no trouble compiling or running unrealircd against a system-installed libtre-0.8.0 on my lappy. I know that the API hasn't changed as the API is POSIX-compatible (and thus the ABI couldn't've really changed). Thus, I don't anticipate any tre-0.8.0-related problems ;-).

2321

ircd

minor

always

2005-02-03 21:21

2010-08-15 06:51

syzop

ohnobinki

normal

resolved

none

fixed

ipv6 clones checking

AFAIK we don't have this, but I think it's kinda needed:

we shouldn't be checking for clones on ipv6 addresses with an *EXACT* IP, but rather on.. well, I forgot, but.. say /64, like most ipv6 ircds do.
Else someone can easily launch like 1000+ clones, and if no oper is present (even if just for a few minutes) you can have not-so-nice-effects :p.

unreal-2321-ipv6-clones.patch (11 KB) 2010-08-13 06:52
unreal-2321-ipv6-clones-r1.patch (11 KB) 2010-08-13 16:34

codemastr

2005-02-04 00:27

Yeah, I guess that's a good idea.

stskeeps

2005-10-30 13:20

that's a bit problematic, since part of that can be encapsulated MAC address, which will be used A LOT in future IPv6 setups. We should invent filters/modules for noticing a sudden rise in connections from certain subnets instead. Perhaps something to kill mirkforce things too?

syzop

2010-07-02 10:01

got reminded by this by someone in #unreal-support.

Technically, no problem to implement this. Just need to think on how to do it configuration-wise (unrealircd.conf). As not everyone would want to limit per /whatever CIDR mask, some would still want to limit by-ip like now.

There are two options I can think of:
1) Global setting, of what is considered an ipv6 clone
2) Per-class setting

Since you might want to make a distinction between clone settings per-netmask, the per-class would be needed. Like, one subnet might have many with per-ip (->special class), while you would like to do per-netmask for all others (->regular client class).

Actually, how about doing both? Having a global setting which is the default for all classes, which can be overridden in each class.

Now as for the name... hmmm.. ipv6-clones-netmask, or something with cidr or bitmask...

set::ipv6-clones-bitmask 32;

not sure.. I'm open for suggestions.

since this only takes little coding to implement and might be quite an issue in some cases I think we should implement this for 3.2.9, if possible.

tabrisnet

2010-07-14 16:59

As the policy from various RIRs is that allocation to end-point (residential) will be /64, and to corporate entities will be /48, making the bitmask 32 is highly unlikely, albeit I wouldn't recommend making there be a minimum size of the mask as much as that we should make it clear in the docs that due to the RIR rules...

syzop

2010-07-14 17:13

I just picked a random value of 32 in my example, if that's what you mean :)
But what's your opinion on the general idea?

This issue is not 100% Release Critical, but is high on my "3.2.9 should have this" list.

tabrisnet

2010-07-14 17:19

No objection to the idea... hell, I'd expand it a bit and by default HIDE the bottom 64 bits including from the cloak. So then one only looks at the top 64 bits for purposes of channel bans & clone counting.

Not to say that we should drop the lower 64bits altogether if they umode -x, or hide it from opers.

ohnobinki

2010-08-11 05:41

So far for config naming, my thoughts are:
/* default of 96, assuming that most people have their own 32 bits */
set::default-ipv6-clones-mask 96;

/*
* the allow blocks would default to set::default-ipv6-clones-mask.
* they would have the option below to override the default.
*/
allow::ipv6-clones-mask <set::default-ipv6-clones-mask>;

For the masks, I would give the user an error if they set the mask to 0 and a warning if it was <= 32. Should I probably warn for <= 64?

syzop: Disallowing 0 would not hurt anyone and would be one way to implement a default allow::ipv6-clones-mask. (If the user doesn't set the allow::ipv6-clones-mask, I could set the variable to 0. After the entire config file is parsed, I would check for allow blocks that have a value of 0 and replace it with the set::default-ipv6-clones-mask. Is this the best/proper way to implement overridable defaults for this case? ;-) ).

syzop

2010-08-11 16:44

Sure, sounds fine.

If I understand correctly, if one would set it to 128 you get the current behavior, right? Just making sure that's still permitted, without warning.
The warning would be just there when illogical configuration is encountered.

I wouldn't mind us setting a default for set::default-ipv6-clones-mask, of like 96... [that would be done in config_setdefaultsettings()]

Yes, the way you describe would indeed be the way to go with regards to setting the allow::ipv6-clones-mask with the set::default-ipv6-clones-mask if the allow:: one is not set.
And yes, I don't see why to permit 0 either ;)

tabrisnet

2010-08-11 16:53

I think there are only 2 sane defaults: 64 and 128. I'm not aware of _any_ RIR that has a policy that ISPs should hand out longer prefixes than /64. Yes, I agree that a /64 is ridiculous, no one could ever use that much address space and a /96 would be more sensible... But the regulations from ARIN (and presumably other RIRs) remain.

Btw, what does this do to cloaking? How are the bits divided among the various components of the cloaks? I know that for IPv4 it was 16/8/8.

If your plan goes something like 16/16/16/16/64, that would probably be reasonable. But I don't seem to remember an IPv6 cloak being that long.

ohnobinki

2010-08-11 17:56

> If I understand correctly, if one would set it to 128 you get the current behavior, right?

Yes, this is perfectly valid. I intend to put this as an example in the documentation when I get this functional.

> I wouldn't mind us setting a default for set::default-ipv6-clones-mask, of like 96... [that would be done in config_setdefaultsettings()]

That's actually about all the progress I made last night ;-).

> Btw, what does this do to cloaking?

As far as I understand, this bug doesn't have anything to do with cloaking or channel bans. It just affects the code that enforces allow::maxperip. (at least, so far...)

syzop

2010-08-12 11:52

Ok, as for the default value for set::default-ipv6-clones-mask: users/admins usually get a /80 (which they subnet themselves to /64) or a /64 directly, right? So then 64 would be a good default?

As for cloaking, that is indeed not what this bugreport is about. tabrisnet: if you would like to put in a request for that, you'd have to open up a new one.

ohnobinki

2010-08-13 06:56

unreal-2321-ipv6-clones.patch: my first complete try at doing this. Tested with ipv6-clones-mask of 128 and 127 and by adding loopback addresses (for 127, ::2 and ::3 overlap, another set of overlapping addresses would be ::12 and ::13).

I changed the defaults mask to 64 bits. I poked at the docs.

Unfortunately, this change leaves AllowClient() in a less readable state.

Any comments more than welcome :-).

syzop

2010-08-13 11:00

I was just taking a quick look, so I might overlook something, but...
the stuff with ipv6_mask_addr in AllowClient():
+#ifdef INET6
+ is_ipv4 = IN6_IS_ADDR_V4MAPPED(&cptr->ip);
+
+ if(is_ipv4)
+ {
+ /*
+ * initialize a mask for IPv6 clones detection. It has
+ * to be zeroed out after aconf->ipv6_clone_mask
+ * bits. Code inspired by match_ipv6().
+ */
+ memset(&ipv6_mask_addr, 0, sizeof(ipv6_mask_addr));
+ i = aconf->ipv6_clone_mask / 8;
+ memcpy(&ipv6_mask_addr, &cptr->ip, i);
+ /* support ipv6_clone_mask not being a multiple of 8 */
+ ipv6_mask_addr.s6_addr[i] |=
+ ~((1 << (8 - aconf->ipv6_clone_mask % 8)) - 1) & cptr->ip.s6_addr[i];
+ }
+#endif /* INET6 */

(after that) it doesn't seem to do anything with ipv6_mask_addr? So either it can be removed or something was forgotten :P. I think the former, since match_ipv6() does all the work?
EDIT: obviously with 'removed' I mean the 'if(is_ipv4)' block, and not the setting of 'is_ipv4' ;)

And something really tiny, but it would continue if I never mention it: I noticed you change 'i++' to 'i ++' here and there (same for errors ++), but since we use varname++ everywhere I would ask you not to (IOTW conform to current style) :)

Other than that, patch looks good, I think. I didn't test it, but it looks clean, has docs, etc... good job. Yet another item smashed, working towards a release :P

Now I should do something too...

ohnobinki

2010-08-13 15:45

> (after that) it doesn't seem to do anything with ipv6_mask_addr? So either it can be removed or something was forgotten :P.

This would be wonderful, but match_ipv6() only fixes up its first argument (addr), not its second argument (mask). It expects mask to be all zeros after the first number of bits specified by match_ipv6()'s third argument (bits). I actually realize that I had forgotten to tie in use of ipv6_mask_addr while waking up this morning ;-). Or that's at least the reason that I wrote that piece of code ;-).

There is an alternative and cleaner method with patching match_ipv6() in cidr.c:
@@ -311 +311,2 @@
- if ((addr->s6_addr[n] & ~((1 << (8 - m)) - 1)) == mask->s6_addr[n])
+ if ((addr->s6_addr[n] & ~((1 << (8 - m)) - 1))
+ == mask->s6_addr[n] & ~((1 << (8 - m)) - 1)))

In fact, I'm going to get rid of the humungous blob you quoted in favor of this ;-).

> I noticed you change 'i++' to 'i ++' here and there

Oops, I didn't realize i++ was the style even though I saw it everywhere.

Thanks for the review :-).

ohnobinki

2010-08-13 16:35

unreal-2321-ipv6-clones-r1.patch: tested with mask of 127 and 96, I think this is ready to commit.

syzop

2010-08-14 19:30

Fine I think? :)

ohnobinki

2010-08-15 06:51

- IPv6 clones detection support (0002321). allow::ipv6-clone-mask determines the number of bits used when comparing two IPv6 addresses to determine if allow::maxperip is exceeded. This allows an admin to recognize that most IPv6 blocks are allocated to individuals, who might each get a /64 IPv6 block. set::default-ipv6-clone-mask defaults to 64 and provides default value for the allow blocks.

3193

ircd

feature

always

2007-01-06 06:13

2010-08-14 20:42

Shining Phoenix

aquanight

normal

resolved

none

i386

Linux

2.6.10-1.771_FC2

3.2.6

fixed

Enable some combinations of extbans

Extbans ~c and ~r are different ways of specifying users, ~n and ~q are different things to do to users. Some new combos could be:
~nc - Users in matching channel can('t) nickchange
~nr - Users with matching realname can('t) nickchange
~qc - Users in matching channel can('t) speak
~qr - Users with matching realname can('t) speak
And if the new simple ewxtban I suggested was added:
~jc - Users in matching channel can('t) join
~jr - Users with matching realname can('t) join

Nice, accurate little extbans. I think anyone who uses ~c and ~r extbans may use these as well :)

Stealth

2007-01-06 11:54

That'd be nice

Bricker

2007-01-06 21:28

this seems way over the top. imo write a module for it, i wouldnt stick it in the core

Shining Phoenix

2007-01-07 00:55

Yeah, but we know how 3rd party modules cause problems =P
I guess I could request a module for this
/me wanders off to the forums

aquanight

2007-01-08 13:42

I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like:

+b ~n:~c:#blah - anyone in #blah can't /nick
+b ~q:~r:*lamer* - anyone with "lamer" in realname can't speak

Note you wouldn't be able to do this the other way around: for example, ~c:~q:#blah wouldn't work.

This could conceivably be done to any extban that would otherwise just take a normal n!u@h mask.

Of course you could then do wierd but useless combinations like ~q:~n:~q:~n:~q:~q:~n:~n:~c:#blah(*) ... but not for me to tell people not to uselessly waste banspace if they really want to do that for some reason.

Bricker:
As it is now, you can't write a module for it - extbans are only allowed one character (another reason why "chaining" as stated above would work better), and you can't "override" extbans like you do commands. Also it wouldn't allow extending this to other extbans, like RegExcept, etc. And if you look at the extban.c code for ~q/~n - it's a change of exactly 1 function call for each of the two (from extban_is_banned_helper to just is_banned) so it's not a stupidly complicated change or anything.

(
(*) == Useless because ~q:blah == match (blah) only during msg check, and ~n:blah == match (blah) only during nick change, so ~q:~n:blah == match (match (blah) only during nick change) only during msg check == can never match.
)

[edit: I should also point out that a chained ban would likely also not work with extban that doesn't ban on the join/nick/msg basis (eg: syzop's textban module). Also I suppose it would be necessary for ~q/~n's "format convparam to forward to the sub-extban's convparam]

Shining Phoenix

2007-01-21 22:58

*Ignore this suggested syntax, look at the next one*

Hmm, I have an idea. What if a user could only set one mode at a time when using an extban? So, when the first parameter after the mode has a ~ in front:

/mode #channel {+|-}<mode> ~<extbans> {extbanparam} {extbanparam} ... {n!u@h}

And when the first parameter after the mode does not have a ~ in front, it is handled normally. That way, you could combine any number of extbans together, e.g.

/mode #channel +b ~jr stupid_bot_script *!*@*.aol.com

Stealth

2007-01-22 13:47

The problem with that, is all the extban params need to be in 1 ban param. Spaces separate params, so it would not work.

Shining Phoenix

2007-01-23 02:42

Umm, read over my suggestion more closely. When someone sets an extban using this system, they can only set one ban mode at a time. Then, since there are no other mode parameters to confuse things, the extban parameters can be seperated by spaces.

aquanight

2007-01-23 09:37

No.

- It would most certainly break clients. Much more than extbans do already.
- It's extra work for the mode parser when simpler solutions are available.

Shining Phoenix

2007-01-23 21:08

*I keep coming up with new ideas, look further down*
Hmm.
mode # +b/e/I ~type1:param1:param2:~type2:param3:param4
So, "after the second colon, before the next :~" would be the definition of param2 in that, then having : within an extban param(e.g. IPv6), and having ~ in an extban param(e.g. ~#chan2) wouldn't be a problem.
I'm fairly sure no extban parameter would have ~: in it.

tabrisnet

2007-01-23 21:11

a) ~T or ~r could contain _any_ characters
b) I back aquanight on this one.

tabrisnet

2007-01-23 21:12

a) chaining ~n and ~q to the extbans sounds interesting.
b) adding multiple parameters is a bit much, and likely impossible.

Shining Phoenix

2007-01-23 21:17

Tabrisnet said:
a) ~T or ~r could contain _any_ characters

Hmm.
1. Don't allow a combo of T and/or r and/or c and/or f
2. Make sure their troublesome parameter is specified last.

Then, the banned text would be "all the stuff after the colon after the ~T:", the banned realname would be "all the stuff after the ~r:", the banned channel would be "all the stuff after the ~c:", and the forwarded channel would be "all the stuff after the ~f:".

...that just disallowed nearly every combo there is...

Or, only allow combos between any number of action extbans, and just one usermatching extban. e.g.

~nq:n!u@h
~jr:realname
~qc:@#lamers
~nqfC:#losers:202.156.345.765/32 <--usermatching param is all after last colon

*More detail below*

aquanight

2007-01-23 22:02

The rule has always been 1 mode has no more than 1 parameter. Only +f and +j break this rule, but they need to. +b does not need to because it's a list mode. People can take the time to do +bbbbbbbbbbbbeIeIo blah....

Also, ~c bans *CAN* start with a tilde. You can use a PREFIX= prefix to match users in the channel with that status or higher. ~r can start with tildes. ~T can start with tildes. If you start saying X ban type has to be last (and you can't core-side enforce that for ~T, it's module-provided, so now you have to somehow let the module say "has to be last"), you completely defeat the purpose of the whole thing. This is exactly why it should stay one extban per +b, no more. Plus now you have to parse something around something other than a space seperator. Basic IRC already takes care of parameters as it is, no need for +b to do extra logic. (Checking for ~, some letter, and : is easy enough, but having to strtok() loop over a :-seperated list is pushing it.) And what is the benefit of it anyway? You don't get any more or less banspace with it (banspace is limited by # of bans and by raw length), and it's simpler to do +bbbb ban1 ban2 ban3 ban4 (and some clients have a command to do it for you, and some might even break it up into multiple /modes if you go over 12 bans).

Extended bans confuse clients enough since they know only of normal bans. Please let's *NOT* confuse them anymore with multiple parameter stuff. One mode, one parameter. It's worked so far, why break it?

It's feasible to chain ~q: and ~n: (and ~j:) onto the other extbans. It's just taking the fact that they already do half the work of normal ban parsing (normal n!u@h), and changing *one* function call (and add forwarding logic in convparam) is enough to have the other half. It isn't feasible to go wild with it and start chaining X00 bans onto the one entry.

[edit: Ick, looks like I was wrong: is_banned is what actually checks the entire banlist (not just one ban). But we could extract the check of the individual ban inside the loop into a function and then just use that.]

Shining Phoenix

2007-01-23 23:12

Hmm. Make ban syntax(I know this is a clumsy way to show it):

mode #chan {+|-}<b|e> {~<{action}{masktype}|{other}:>}<mask>

All extbans would be either action, masktype or other. Put all extbans in modules perhaps?

Where action currently is = j|n|q|jn|nq|jq

Masktype currently is = C|E|r|c

Other currently is = T

{optional}
<required>
option1|option2

Bricker

2007-01-27 17:04

jesus H christ! FIX IT ALREADY! ;P

Shining Phoenix

2007-01-31 03:23

aquanight said:
I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like:

+b ~n:~c:#blah - anyone in #blah can't /nick

I say:
Would +b ~n:~c:~#blah work?

JasonTik

2007-02-01 18:12

This conversation is getting weird. I agree with aquanight. The ~q:~c:#Chan chaining stuff is the way to go.

Also: A ~j: would be very nice. As it is, a normal ban is ~j & ~q

Shining Phoenix

2007-02-01 20:34

Err, a normal ban is ~q, ~j and % or higher required to nickchange >.>

Well, if you're sure about the chaining, ok. A lot of ~: to type =(

Shining Phoenix

2007-05-07 20:33

*bump*

Chained extbans would be a good feature, e.g.
+b ~n:~c:~#lame_guys_channel

Modules that provide extra extbans would need to be fixed afterwards to take advantage of this feature...especially m_hostforward (extban ~f).

Disallowing colons in channel names, which I believe is going to be done in future, will make chained extbans more doable.

syzop

2007-05-08 04:24

aquanight wanted to do this but, basically I said waaaaah waittt ;P

But I'd be fine if you (aquanight) would again look into it... with a few remarks:
* Things should stay very fast, ban checking is one of the most important CPU eating tasks in the IRCd (top 5).
* The code shouldn't be cluttered too much, aka "try to keep the code nice"
* There should be a config option to disable this feature (for speed/personal preferences/etc)
* Should only allow one combination like ~q:~c:#chan and not like ~q:~c:~c and such ;p
* You're right, be careful with allowing which extbans to be extended, sometimes ~ may be used in the extban itself already, so that means it could not be extended or else you get confusion. I guess extbans should somehow set a flag (on init/load/whatever, in the extbanadd thing) whether they'd allow them to be extended or not. ~q and ~n look a good place to start.

So like point 1 (speed), if you'd split things to 'check whole banlist' and 'check individual ban' functions, be sure to tag the 2nd as inline, and.. also use the n!u@h buffers (std, ip, cloak, etc) in that function and don't go rebuild them for every ban... you get the idea.

well, you probably get a good idea how to do things then, have fun ;P

*****

Then on ~j.. that deserves a separate report, with some good explanation over there why it would be useful.

Shining Phoenix

2007-05-10 21:54

~j at http://bugs.unrealircd.org/view.php?id=3192 [^]

aquanight

2007-05-12 10:05

Going with the chained extban deal. To sum up what's basically going to happen:
- Any extban (like, say, ~q) that normally uses (as either all or part of their parameter) a nick!user@host mask, can instead choose to allow sticking an extban in its place. So eg for ~q:nick!user@host, you could then do ~q:~c:#stfu.
- It will be up to each extban to decide if it wishes to allow stacking extbans or not. The current extban_is_banned_helper() function that allows extbans to easily do n!u@h matching will remain as it is (= no extban stacking) for compatibility.
- An extban that wishes to allow stacking will call a function like ban_check_mask, which will do n!u@h, or extban, as appropriate. Such extbans also need to arrange for convparam forwarding.
- Since extbans are in control of whether or not extbans stack, they are given responsibility for dealing with any stacking limits they might want to impose, or to, say, collapse wasteful things like ~q:~q:~q:~q:~q:blah, to ~q:blah.
- I'm still considering whether to control this behavior with a ./Config option or unrealircd.conf option, or indeed if such an option is really needed at all. I can understand the whole "personal preferences" deal though, and I'm leaning toward ./Config option since that way will ensure modules have to respect it (as if they don't, they won't compile when support for it is switched off :P ).

aquanight

2007-05-13 17:19

Added to devel (3.3*) CVS, .2397

I'll do a slightly better write-up or something when I have time. Put simply, though, existing modules don't have to change unless they want to deal with chained extbans, but core extbans now support chaining. For compatibility, an Config option disables this support, and makes extbans work pretty much exactly as it did before. (So basically, modules can still support this and be ok in 3.2 because of the #define.)

- Added support for "chained" extbans. Put simply this allows extban combinations
  such as ~q:~c:#test to only silence users on #test, for example. This feature
  is enabled by default, but can be disabled during ./Config -advanced. Module
  support for this feature must note the following:
  - For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which
    will deal checking a chained extban (including checking for restricted extbans),
    or it can call that function from its own is_ok routine. For the latter case,
    remember to pass only the mask part of your ban format (ie, don't just pass para as
    otherwise it'll just call your is_ok again).
  - For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban,
    which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask.
  - For is_banned, the extban should call ban_check_mask with the mask part of the parameter.
    This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h
    is checked against the current user (ie, with the info in the globals ban_ip, etc), so things
    can get weird if you call this outside a normal ban check.
  Modules must keep in mind that chained extban support is not available (and neither are the three
  functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will
  not compile/load if they try to use them anyway.
  This change should not break extban modules, and should need some more extensive testing.

Shining Phoenix

2008-09-03 04:21

The problem with combining extbans is that if you can combine some but not others, then you have to remember which can and can't be combined, which makes it more complex. If any extbans could be combined in one ban, then this topic gets simpler. If there was one magic character that could seperate the parameters of each extension, then you could do +b ~thing1:~thing2:param1<magic character>param2
An analogy for this is that the magic character in mode lines is a space, ie /mode #channel mode1mode2 thing1 thing2
The sticking point here is that I couldn't think of a suitable magic character for seperating the parameters of a chained ban.
Today I think I figured it out.
<magic character> is a semicolon
As far as I know, semicolons are never in the host part of nick!ident@host, nicknames, CIDR bans or server names. So all that's left to worry about are channel names and real names. If semicolons are disallowed in channel names and real names, then semicolon won't be used within the matching bit of any extban (except T, I'll get to that later), so it can be used as the magic character.
To diallow semicolons in real names, I suggest that ; gets changed to T, so that if a person has ;-; in their real name it changes to T.T, hence retaining its original meaning.
Chaning textban ~T with other extbans is doomed to fail, so it simply shouldn't be allowed. So yeah, people would need to remember that T doesn't chain, but that's easier to remember than "c, C and r (and s if unreal has it) don't chain with each other".

syzop

2010-08-14 20:41

Added in CVS mass-commit .863:
- This is actually an update of earlier code from CVS, but now it works ok:
- Added support for "stacked" extbans. Put simply this allows extban combinations
  such as ~q:~c:#test to only silence users on #test, for example. This feature
  is enabled by default, but can be disabled during ./Config -advanced.
  This feature was suggested by Shining Phoenix (0003193), was then coded
  by aquanight for U3.3, and later on backported and partially redone by Syzop.
  Module coders:
  In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:
  Since stacked extbans only makes sense where the 1st one is an action
  extended ban like ~q/~n/~j, most modules won't have to be changed, as
  their extban never gets extended (just like ~c:~q: makes no sense).
  However, you may still want to indicate in some cases that the extban your
  module introduces also shouldn't be used as 2nd extban.
  For example with a textban extban ~T it makes no sense to have ~n:~T.
  The module can indicate this by setting EXTBOPT_NOSTACKCHILD in
  the ExtbanInfo struct used by ExtbanAdd().
  For completeness I note that action modifier extbans are indicated by
  EXTBOPT_ACTMODIFIER. However, note that we currently assume all such
  extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban
  functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things
  will go wrong with regards to stack-counting.
  Module coders should also note that stacked extbans are not available if
  DISABLE_STACKED_EXTBANS is defined.
- Added extended ban ~R:<nick>, which only matches if <nick> is a registered
  user (has identified to services). This is really only useful in ban
  exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he
  has identified to NickServ. This is often safer than using +e n!u@h.
- Added Extended Invex. This is very much like extended bans, in fact it
  supports some of the same flags. Syntax: +I ~character:mask
  Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
  This can be useful when setting a channel invite only (+i) and then
  setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
  still being able to ban users.
  Because action modifiers (~q/~n/~j) make no sense here, extended invex
  stacking (+I ~a:~b:c) makes no sense either, and is not supported.
  Suggested by DanPMK (0002817), parts based on patch from ohnobinki.
  Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
  ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
  it checks them also when the user is not currently cloaked (eg: did -x, or
  is currently using some VHOST).
- Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).

3928

ircd

major

always

2010-07-14 17:32

2010-08-14 20:40

syzop

normal

resolved

none

fixed

Fix chained/stacked bans

Just a TODO item to remember me fixing chained/stacked bans.
It should not be in 3.2.9 release in it's current state.

syzop

2010-08-14 20:40

Fixed in CVS mass-commit .863:
- This is actually an update of earlier code from CVS, but now it works ok:
- Added support for "stacked" extbans. Put simply this allows extban combinations
  such as ~q:~c:#test to only silence users on #test, for example. This feature
  is enabled by default, but can be disabled during ./Config -advanced.
  This feature was suggested by Shining Phoenix (0003193), was then coded
  by aquanight for U3.3, and later on backported and partially redone by Syzop.
  Module coders:
  In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:
  Since stacked extbans only makes sense where the 1st one is an action
  extended ban like ~q/~n/~j, most modules won't have to be changed, as
  their extban never gets extended (just like ~c:~q: makes no sense).
  However, you may still want to indicate in some cases that the extban your
  module introduces also shouldn't be used as 2nd extban.
  For example with a textban extban ~T it makes no sense to have ~n:~T.
  The module can indicate this by setting EXTBOPT_NOSTACKCHILD in
  the ExtbanInfo struct used by ExtbanAdd().
  For completeness I note that action modifier extbans are indicated by
  EXTBOPT_ACTMODIFIER. However, note that we currently assume all such
  extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban
  functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things
  will go wrong with regards to stack-counting.
  Module coders should also note that stacked extbans are not available if
  DISABLE_STACKED_EXTBANS is defined.
- Added extended ban ~R:<nick>, which only matches if <nick> is a registered
  user (has identified to services). This is really only useful in ban
  exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he
  has identified to NickServ. This is often safer than using +e n!u@h.
- Added Extended Invex. This is very much like extended bans, in fact it
  supports some of the same flags. Syntax: +I ~character:mask
  Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
  This can be useful when setting a channel invite only (+i) and then
  setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
  still being able to ban users.
  Because action modifiers (~q/~n/~j) make no sense here, extended invex
  stacking (+I ~a:~b:c) makes no sense either, and is not supported.
  Suggested by DanPMK (0002817), parts based on patch from ohnobinki.
  Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
  ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
  it checks them also when the user is not currently cloaked (eg: did -x, or
  is currently using some VHOST).
- Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).

2817

ircd

feature

N/A

2006-02-13 11:56

2010-08-14 20:40

DanPMK

syzop

normal

resolved

none

any

3.2.5

fixed

Request: Extended Invex

Exteneded bans is one of my favorite features with Unreal, yet it only works with +b and +e. Any chance this could be added to work with the +I Invite exceptions?

Stealth

2006-02-13 23:14

This could be fun...

Shining Phoenix

2007-01-28 03:06

Soo...is this going to be implemented?

tabrisnet

2007-04-15 17:38

fun doesn't mean good.

syzop

2007-05-07 12:38

I suppose it isn't a too bad idea?
Like +i and +I ~c:#somechan, that's safer than +b *!*@* +e ~c..
just as an example.

oh wait.. I already confirmed it ;)

Shining Phoenix

2007-07-27 04:26

Like +i and +I ~c:#somechan, that's safer than +b *!*@* +e ~c..
just as an example.
------
That's a good idea, I like to minimise use of exceptions. And I would use +I ~c

syzop

2007-09-06 13:02

I suppose this would be quite easy to implement, huh? /me looks at aquanight and wolfsage
Would be nice to have at least 1 new interesting feature in 3.2.8, if not too hard.

syzop

2010-08-14 20:39

Fixed in CVS .863:
- Added Extended Invex. This is very much like extended bans, in fact it
  supports some of the same flags. Syntax: +I ~character:mask
  Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
  This can be useful when setting a channel invite only (+i) and then
  setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
  still being able to ban users.
  Because action modifiers (~q/~n/~j) make no sense here, extended invex
  stacking (+I ~a:~b:c) makes no sense either, and is not supported.
  Suggested by DanPMK (0002817), parts based on patch from ohnobinki.
  Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
  ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
  it checks them also when the user is not currently cloaked (eg: did -x, or
  is currently using some VHOST).

3942

ircd

feature

have not tried

2010-08-05 22:05

ohnobinki

low

new

none

3.2.9

open

typechecking for module hooks

It would be nice to make it harder to mismatch hooks. For example, the compiler could detect that hooks are being mismatched if each hook is given a function prototype typedef or something. Or, maybe this could be as simple as a function like:

HookAddExArg(Module*, int hooktype, int (*intfunc)(), int num_args);

Assumably, if a hook changed its interface, the number of arguments passed to the hook would also change.

Maybe this idea is completely pointless. Unrealircd could just choose to never change the signatures of hook functions. If a hook needed to be changed, it could be renamed to HOOKTYPE_BLAH_V2 or something.

3932

installing

minor

have not tried

2010-07-15 13:07

2010-08-04 03:38

syzop

ohnobinki

normal

resolved

none

3.2.8

fixed

Update c-ares to latest version

...just like TRE 0003916, this has to be done before 3.2.9 release.

ohnobinki

2010-08-04 03:38

In CVS.

- Upgraded c-ares to 1.7.3. API seems compatible with c-ares-1.6.0. (0003932)

3939

ircd

minor

always

2010-07-20 04:44

2010-08-04 02:04

warg

ohnobinki

normal

resolved

none

3.2.9

fixed

patch to fix for various compiler warnings

patch fixes these warnings:

# GCC 4.4.4
ssl.c: In function ‘ssl_get_cipher’:
ssl.c:437: warning: assignment discards qualifiers from pointer target type

# GCC 4.3.2
s_user.c: In function ‘check_for_target_limit’:
s_user.c:463: warning: cast from pointer to integer of different size

# GCC 4.3.2
support.c: In function ‘encode_ip’:
support.c:1824: warning: cast to pointer from integer of different size

warg-warn-fix.patch (1 KB) 2010-07-20 04:44
unreal-3939-fix-casts-const.patch (3 KB) 2010-07-22 19:29

syzop

2010-07-22 12:19

I wonder if binki can spot the error in this patch ;)

ohnobinki

2010-07-22 14:08

base64 encoding a pointer instead of an IP address?

I'd have to look at the context to verify the last two chunks of the patch.

syzop

2010-07-22 15:22

exactly.. in chunk 2 and 3 you now deal with the pointer itself, which would result in broken nickip and broken target flood detection.

3 obviously just not add the & I think.
for 2.. if you look at the CURRENT code, it's pretty mysterious :P. Basically a pointer is set to the value of the ip (aka: to the IP itself), and then the pointer is b64encoded. Ok, that might work, but is rather... odd. presumably for 2 the & as in the patch should be done, and the & should be removed for the b64_encode in the line under it? Or maybe you could even do without using 'cp' in that part. I did not test...

If you, binki, would like to take this, and test it, then feel free to commit for 3.2.9. (assuming you're not going to rewrite the whole function... but just those few lines :D)

warg

2010-07-22 16:42

sorry for my mistake

ohnobinki

2010-07-22 19:30

unreal-3939-fix-casts-const.patch: use double-casting to make GCC happier.

syzop

2010-07-24 22:19

does this work on non-C99 compilers, binki? Like will it define those types if they don't exist... (see our coding guideline nr 9)

also, like I said for 2.. I'd rather like:
- cp = (u_char *)ia.s_addr;
- b64_encode((char *)&cp, sizeof(struct in_addr), buf, 25);
+ b64_encode((char *)&ia.s_addr, sizeof(struct in_addr), buf, 25);

assuming that fixes the warning for warg too...
warg, could you test that?

On a side note warg, looking at your warnings, they are 64 bit related I think [except for nr 1 of course] :). I can't test it, as I don't have a 64 bit system.

If all from above is satisfied, then feel free to commit.

ohnobinki

2010-07-25 03:04

> does this work on non-C99 compilers, binki? Like will it define those types if they don't exist... (see our coding guideline nr 9)

The documentation for AC_TYPE_INTPTR_T claims that these types will be defined. Like you can't test the 64-bit-related problems, I can't test this ;-). I suppose that #define-ing this in win32's fixed setup.h would be the correct solution? And hopefully win32 means no 64-bit support...?

syzop

2010-07-25 20:07

yea, think so :)

ohnobinki

2010-08-04 02:04

- Fix a few compiler warnings with some double-casting and another const. (0003939)
- Define intptr_t in win32's setup.h. (0003939)

I didn't test much other than that the unrealircd runs, links in normally, and works with clients like I'd expect it to. I.e., I don't know what circumstances cause encode_ip() to be used or how to test the throttling code.

Oh, and I can only hope that my #define in win32/setup.h works ;-).

3934

documentation

minor

have not tried

2010-07-15 13:10

2010-07-23 23:49

syzop

normal

new

none

3.2.8

open

Update translations

Once the docs are finalized, so when at RC1, I need to send the updates (diffs) to the translators.
Preferably, restore the translators mailing list, as it's currently not functioning.

Also, need to go through outdated translations -- preferably BEFORE rc1. Some have not been touched for like 2 or 3 years and should maybe be scheduled for removal?

Bock

2010-07-15 13:49

Maybr not removal, mark as depricated and ask people via site what we want new translators :]

syzop

2010-07-15 15:55

Yeah, and I should act on those abandoned docs now.

I just posted a message on the forums, see http://forums.unrealircd.com/viewtopic.php?f=15&t=6611 [^] asking for Spanish and Greek translators
EDIT: .. and Dutch, I don't like doing that myself ;p

Last updates (excluding myself doing version changes):

Spanish: Sat Dec 2 11:11:39 2006 UTC
Greek: Sat Dec 2 09:56:07 2006 UTC
Turkish: Fri Jul 13 23:02:47 2007 UTC
French: Fri Dec 21 16:45:02 2007 UTC

I think for French and Turkish I might still be able to prod them to get things up to date. I'll try that first before asking new people ;)

Only the German, Russian and Hungarian translated docs are somewhat up to date (.. I'm not counting 6 months out of date).

vonitsanet

2010-07-23 23:49

I can help a bit with the Greek language. :-)

3192

ircd

minor

always

2007-01-06 06:01

2010-07-22 14:36

Shining Phoenix

ohnobinki

normal

resolved

none

i386

Linux

2.6.10-1.771_FC2

3.2.6

fixed

Add a new simple extban

Ban mode +b ~j:stuff would only stop matching users from joining, not nickchanging and speaking. It's corresponding exception (+e ~j:stuff) would only let matching users join, and not affect speaking and nickchanging. If I want to let someone join, but not speak or nickchange, this would do the job well :)

unreal-3192-m_extban_join.patch (5 KB) 2010-07-20 18:47
unreal-3192-extban-modej.patch (3 KB) 2010-07-22 01:04

Sakkath

2007-01-09 07:52

Why not use ~q and ~n?

Sakkath

2007-01-09 07:52

I mean honestly, why let a person in the channel if they have absolutely no rights? The other extbans I find are useful enough?

Shining Phoenix

2007-01-14 02:51

There was some specific purpose for this, but now I've forgot it.

Sakkath

2007-01-14 10:01

Lol.

aquanight

2007-01-15 15:48

Well, +b ~j I can see useful: you want people of a specific hostmask have to be invited (for example, particularly annoying ISPs like AOL: you can +b ~j:*!*@*.aol.com, and they have to be /invited, but once allowed in, can speak/nickchange freely - you might give a few "known good" people access to /chanserv INVITE themselves), but anyone else can join fine. +e ~j just gets a "free ride" on account of the fact that +b/+e pretty much use the same system (yes I see nearly no use for that).

syzop

2007-01-15 16:01

thanks for the example aquanight. without it, this had little chance :P

Sakkath

2007-01-15 20:08

Most people would probably not even see that this function exists, but since so many of us use UnrealIRCd, now that you've posted an example, I guess some would find it useful.

Thanks for the ex :-p.

This might be best as a module too keep the core's "core" functionality and not have stuff some might find unnecessary :-p.

Shining Phoenix

2007-01-21 22:39

I had a situation where I wanted to use it today :)
This guy was cloning in a channel where I don't allow it, so I set a ban on him, a nickchange exception and a quiet exception. A single ~j ban would be nicer than a ban and two exceptions.
Modifying the core to add this feature would be better than having someone make a module for it, which will crash the IRCd.
/me stabs 3.2.6's handling of parametered channel modes from modules D:<

syzop

2007-01-22 06:21

This can be perfectly fine implemented in a module. Of course, you're right, if you don't know C or are unable to create a good UnrealIRCd module, then it could crash. Just don't say it's not possible!

aquanight

2007-01-25 11:27

Added (to core) in devel branch .2333 .

syzop

2010-07-14 21:15

reopened for 3.2.9

syzop

2010-07-20 20:48

Ehm.. regarding the patch.
Yes, I understand you want it modulized, as it can be loaded if the user wants it.
But, please just integrate it with the other extbans for now, there's no reason to make an exception to ~j when ~c/r/n and such are already in the core.

Perhaps in 3.2.10 / 3.3 we can choose to modulize stuff some more, but for now just do it like the rest.

ohnobinki

2010-07-20 21:03

> But, please just integrate it with the other extbans for now, there's no reason to make an exception to ~j when ~c/r/n and such are already in the core.

OK, it just appeared from the thread above that it should be a module ;-).

syzop

2010-07-20 21:19

ah, now I re-read it, I understand how it appeared that way ;)

ohnobinki

2010-07-22 01:05

unreal-3192-extban-modej.patch: integrates into core using existing conventions.

syzop

2010-07-22 11:47

Good :)

ohnobinki

2010-07-22 14:36

In the original patch in help.conf, I refered to ~j as ~r and had grammar mistakes -- fixed before applying.

- Add an extbasn of the schema +b ~j:*!*@* which _only_ prevents a user from joining a channel. (0003192)

in CVS :-).

3133

documentation

minor

always

2006-12-02 10:49

2010-07-22 14:04

syzop

ohnobinki

normal

resolved

RC1

none

ANY

3.2.6

fixed

Add SSL client cert documentation (oper, link blocks, etc)

Document that we allow the 'sslclientcert' password authentication everywhere (like in place of 'md5' etc), if SSL is enabled.

It would be nice if this could be explicitly documented somewhere, maybe in the oper block (see 'additional information' field below).

It's also extremely useful for server links, probably good idea to explicitly document it there as well.

Of course any other suggestions or attempts as to how to put this in the docs are welcome as well.

Actually, maybe we could make a section which explains all authentication methods supported (md5, crypt, sslclientcert, etc) and refer to that from each section. Currently it's a mess that we have to repeat the list 'valid blalba methods are: md5, crypt, ..' at like 5 places ;P.

Still, I think a seperate "howto" section for oper certs and link blocks would be a good idea.

It's a shame this nice feature is completely undocumented atm ;)

Bricker made a start on this (well, oper client certs), attached.
Probably at least part of it can be (re)used :)

UnrealSSLDocs.doc (96 KB) 2006-12-02 10:49

Bricker

2006-12-06 19:13

So basically, instead of how I had it setup for just the operblock, you wan an entire section for using SSL Certs? I'll (write) another one, and see if anyone else doesnt wanna edit it, or add to it

WolfSage

2007-04-18 16:24

*Punts Bricker* Well? ;)

Bricker

2007-04-18 20:30

pft, sure i'll get on it over my weekend. ty again for reminding wolfsage

stskeeps

2007-06-12 15:26

*Punts Bricker again*

Bricker

2007-06-12 17:36

my bad guys, i just dont remember stuff that well anymore. kick me in the channel tonight and i'll get on it

syzop

2010-07-14 17:29

I don't know about what exact text, but it would be nice to finally have some text about this in 3.2.9....

ohnobinki

2010-07-22 01:22

- Remove browser compatibility listing from HTML docs.
- Added information about ``oper::password::auth-type sslclientcert'' and the same for link::password-receive::auth-type. (0003133)
- A little bit more of interlinking and using id="" instead of <a name="" />

I'm not sure if my changes are enough to resolve this bug.

syzop

2010-07-22 11:45

Yup, looks sufficient :)

(I only did some really minor edits, like moving 'crypt' up in your list, as to make it sorted from easiest to hardest to crack, and some caSE edits when I was at it)

3941

installing

trivial

always

2010-07-22 12:00

2010-07-22 13:57

ohnobinki

normal

assigned

CVS 2010.07.20

none

amd64

Gentoo

2.0

3.2.8

open

pkg-config support for curl

I get a false warning about libcurl not having c-ares enabled at compiletime. I pasted proof into Additional Information.

I suspected that ./Config would make the same mistake, but in my quick test it didn't.

1. Use Gentoo :-)
2. Install curl into the system with cares support enabled

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for TRE... yes
checking for CARES... yes
checking /usr/bin/curl-config... yes
configure: WARNING: cURL is compiled without c-ares support. Your IRCd will possibly stall when REHASHing!
checking curl_easy_init() in -lcurl... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/modules/Makefile
config.status: creating unreal
config.status: creating ircdcron/ircdchk
config.status: creating include/setup.h
config.status: include/setup.h is unchanged
ohnobinki@ohnopublishing ~/unreal.0 $ echo :-O
:-O
ohnobinki@ohnopublishing ~/unreal.0 $ eix -e curl
* dev-haskell/curl
     Available versions: ~1.3.5 {doc profile}
     Homepage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl [^]
     Description: Haskell binding to libcurl

[I] net-misc/curl
     Available versions: 7.20.0-r2{tbz2} ~7.20.1 ~7.21.0 {ares gnutls idn ipv6 kerberos ldap libssh2 nss ssl test threads}
     Installed versions: 7.20.0-r2{tbz2}(21:21:37 05/05/10)(ares gnutls ipv6 kerberos ldap lib32 ssl test -idn -libssh2 -nss)
     Homepage: http://curl.haxx.se/ [^]
     Description: A Client that groks URLs

Found 2 matches.
ohnobinki@ohnopublishing ~/unreal.0 $ echo 'I see my ares enabled up there...'
I see my ares enabled up there...
ohnobinki@ohnopublishing ~/unreal.0 $ readelf -d /usr/lib64/libcurl.so |grep libcares
0x0000000000000001 (NEEDED) Shared library: [libcares.so.2]
ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --configure | grep -o -e '.--enable-c\?-\?ares.'
'--enable-ares'

You may find interest in:

ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --libs
-lcurl
ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --static-libs
/usr/lib64/libcurl.a -Wl,--as-needed -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--hash-style=both -lcares -lldap -lrt -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march=athlon64 -combine -ftree-vectorize -falign-functions=16 -falign-labels=16 -falign-jumps=16 -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march=athlon64 -combine -ftree-vectorize -falign-functions=16 -falign-labels=16 -falign-jumps=16 -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lz -lgnutls

Note that --static-libs's output may include libs required for dependencies of libcurl.a. That is, if libcurl uses another library that requires -lcares, curl-config --static-libs will list -lcares even if curl wasn't compiled with support for it.

unreal-3941-pkg-config-libcurl-r1.patch (10 KB) 2010-07-22 13:56

syzop

2010-07-22 12:07

> I expect the pkg-config support half of this is more controversial. Also, I can remove the hint to the user about forcing compilation against a libcurl that doesn't have cares if you want ;-).

Yes, please remove.. we don't want to encourage users doing silly things :)

Anyway --> 3.2.10

ohnobinki

2010-07-22 13:57

unreal-3941-pkg-config-libcurl-r1.patch: removed message about avoiding libcares check :-p. Will be committed when the repo is open for 3.2.10.

3940

installing

trivial

always

2010-07-20 16:03

2010-07-22 12:02

ohnobinki

normal

resolved

CVS 2010.07.20

none

amd64

Gentoo

2.0

3.2.8

fixed

./configure claims curl doesn't have cares enabled, could use pkg-config

1. Use Gentoo :-)
2. Install curl into the system with cares support enabled

unreal-3940-pkg-config-libcurl.patch (11 KB) 2010-07-22 01:13

syzop

2010-07-20 16:22

Perhaps have a look at my ./Config check I put in a few days ago. It does a proper check by doing curl-config --features and checking for AsynchDNS :)

ohnobinki

2010-07-22 01:15

unreal-3940-pkg-config-libcurl.patch: Add pkg-config support for curl, detect features properly in ./configure.

I expect the pkg-config support half of this is more controversial. Also, I can remove the hint to the user about forcing compilation against a libcurl that doesn't have cares if you want ;-).

syzop

2010-07-22 12:02

- Fix the detection for curl-without-c-ares a little (0003940).

Sorry for stealing your bug slightly... but I wanted a simple fix :P.
I tried to clone this bug to 0003941, so to make a separate bug for pkg-config support -> 3.2.10, but it seems it does not really clone it, as it didn't copy the attachement!

3937

installing

feature

have not tried

2010-07-16 13:12

2010-07-20 20:42

syzop

normal

confirmed

none

open

Automatic compiling and installing of 3rd party (custom) modules

It would be nice to have some sort of way that if you put a 3rd party module in src/modules (or src/modules/somespecialdir) Unreal would automatically compile it too when doing 'make', avoiding the need to do 'make custommodule MODULEFILE=xyz'.

It would be even better if like 3rd party modules would ship with an extra file or something that would specify if there are any EXLIBS=xyz needed. Like in some blah.c.def file or something.

Basically, this way a user can easily upgrade, or adjust (major) settings, and then do 'make' and 'make install', and everything is OK, rather than having to think each time 'oh wait.. I have to run this and that command too'.

Keep backward compatible: keep supporting the current 'make custommodule MODULEFILE=xyz' way, though.

unreal-3937-with-custom-modules-r0.patch (25 KB) 2010-07-20 18:41

ohnobinki

2010-07-20 18:45

unreal-3937-with-custom-modules-r0.patch: A cleanup of src/modules/Makefile.in and addition of --with-custom-modules= to ./configure. Oh, I had made modifications to ./Config to integrate with the ./configure part, I'll post them when I remember to find them ;-).

This would be the easiest way of solving the problem of automatically handling users' modules. It makes sense to me to define that list of modules at ./configure time and it's not too hard for a user to re-run ./Config (as long as he uses --with-system-cares and --with-system-tre so that he doesn't have to recompile TRE and cares ;-) ).

syzop

2010-07-20 20:42

I would much rather want it like I said. If you put the module in a certain directory, that they get compiled automatically. The EXLIBS= stuff as mentioned would then be 'nice' if possible, too.

IMO it's not a good idea to force the user to re-run ./Config when he adds a module.

anope basically does it like I described (except for the EXLIBS stuff, but that would be just a bonus, not a requirement). You drop the module in the dir, and it gets compiled.

Anyway, nothing urgent, 3.2.10 ;)

3938

installing

trivial

have not tried

2010-07-18 20:58

2010-07-20 18:10

ohnobinki

normal

resolved

CVS

none

3.2.8

fixed

Trigger rebuild on ./Config changing remote includes or zip links

I noticed that editing any header file in include/ caused a complete rebuild of unrealircd. Thus, when I decided to rebuild an unrealircd that didn't have remote includes enabled as having remote includes enabled, I was surprised to see that the only file that got recompiled was url.c.

This patch moves _SOLARIS, USE_LIBCURL, and ZIP_LINKS into setup.h by using AC_DEFINE([BLAH]) instead of CFLAGS="$CFLAGS -DBLAH".

I'm pretty sure that this will reduce the number of support requests in #unreal-support which are answered with ``just run `make clean all' and it'll work''.

unreal-configure-rebuild-fixes.patch (2 KB) 2010-07-18 20:58
unreal-configure-rebuild-fixes-r1.patch (3 KB) 2010-07-19 18:53

syzop

2010-07-19 12:12

Sounds like a good idea.

First part: zip & remote includes, good.

As for the SunOS/Solaris change..
I don't know about either from the top of my head, so I'll just ask:
1) Is | in case permitted in POSIX bourne shell (not talking about bash)?
2) The _SOLARIS symbol, was it just defined for use by us, or does it also do something in the other (libc) header files, just like _OPEN_SOURCE etc etc

As for the last part regarding FD_SETSIZE, even though you have a case there, I'd rather have you remove that part and not sound alarm bells in pretty much every compile. Perhaps you can think of a better idea (setting a dummy variable to the value of FD_SETSIZE in setup.h? -- I dunnow).

Anyway, the fd thing is lower priority, sunos/solaris not important, but the zip & remote includes thing would be nice to have in 3.2.9.

ohnobinki

2010-07-19 18:52

1. http://www.opengroup.org/onlinepubs/7990989775/xcu/chap2.html [^] shows `|' being used in case statements.
2. I'm pretty sure that _SOLARIS is only defined for our own sake. I'm very sure that it's unrelated to _XOPEN_SOURCE and _GNU_SOURCE, etc.. It's not listed at feature_test_macros(7). I still think it would just be cleaner to use AC_DEFINE for _SOLARIS instead of CFLAGS="$CFLAGS -D", etc.
3. I can strip the FD_SETSIZE warning. I think a dummy variable in setup.h is unnecessary and would cause confusion. Also:
- there is faint hope of poll() support in the next 10 years :-p
- those who have messed with the FD_SETSIZE stuff hopefully know to recompile... err... perhaps any docs which mention MAXCONNECTIONS would say you need to recompile(?).. nevermind ;-)

syzop

2010-07-20 11:31

Ok, thanks for checking. Throw the -r1 in :)

ohnobinki

2010-07-20 18:10

In CVS. :-)

- Now define _SOLARIS, USE_LIBCURL, and ZIP_LINKS in setup.h instead of the Makefiles. This means better automatic rebuilds if the latter settings change.

3925

installing

minor

always

2010-07-12 21:36

2010-07-20 12:02

warg

normal

new

none

Linux & BSD

3.2.8

open

curlinstall broken

when using curlinstall script, curl.h is non existent in $HOME/curl/include, and this causes unreal's compile to fail. This is probably on the curl vendor end, but a simple fix is doable - patch attached.

using c-ares-1.7.3
using curl-7.21.0

run the ./curlinstall as documented, then try to compile unreal.

ircd.c:75:23: error: curl/curl.h: No such file or directory

http://forums.unrealircd.com/viewtopic.php?f=3&t=6608&start=0 [^]

curlinstall.patch (0 KB) 2010-07-12 21:36

warg

2010-07-12 22:59

NOTICE: my patch didn't correct this issue, working on other options.

syzop

2010-07-13 17:45

Huh? How can they forget to install curl.h? That sounds rather silly...
You sure? :P

Sorry no time to test atm.

syzop

2010-07-15 13:04

I've tried installing with the auto-installer (so answering Yes to the automatic install question) with latest CVS, though I had to fix this bug first before I could:
- The patch from 0003888 made ./Config favor the curl in /usr, even if it
  was not compiled with c-ares, which is clearly a bad idea as then the
  entire IRCd can hang for several seconds or more...
  We now check if they support asynch DNS, and skip them if they don't.

AND... this bug 0003931 needs to be fixed, I ripped out the check locally but it's not in CVS because maybe binki can fix it without removing the check altogether -- like by moving the check to the end.

Anyway, then it compiles fine.

When I was at it, I also updated our curl-latest.tar.gz to the latest version (7.21.0 - same as you), and that too compiles fine.

Yay :)

Anyway, you better wait till 0003931 is fixed before checking if it works for you too.

warg

2010-07-20 04:57

@0016147 yeah it is silly, but on my end it's what happened, and iirc i showed binki in a screen session. i'm really out of swing on the bug posting, having been away for atleast a couple years, so my apologies for leaving information out and such. i'll get back to you on this soon.

syzop

2010-07-20 12:02

No need for apologies ;)
Maybe you could check with latest CVS, now the last bugfix was checked in. Perhaps even rename the curl to curl.old before you try it, so you can also test our new auto-install thingy.

Also, since I don't know if you meant it literally: curl.h is never in ~/curl/include itself, but rather in ~/curl/include/curl/curl.h (as to make #include <curl/curl.h> work, just like with openssl, etc).

3919

ircd

minor

always

2010-07-10 00:32

2010-07-19 11:52

warg

ohnobinki

normal

assigned

1.1.1.1.2.1.2.1.2.2234.2.827

none

CentOS

5.5

3.2.8

open

recursive inclusion of unrealircd.conf causes hang and excessive cpu usage

If I do include *.conf;, unreal is trying to recursively include unrealircd.conf, so it hangs at * Loading IRCd configuration .. and ignores SIGINT.

It may be stupid to include *.conf; (my opinion), this should not be expected behavior.

Compile UnrealIRCd and include *.conf; in unrealircd.conf.

I've attached a screenshot of useful/relevant data.

Screenshot.png (280 KB) 2010-07-10 00:32
unreal-recursive-includes-error.patch (15 KB) 2010-07-18 21:01
unreal-recursive-includes-error-r1.patch (15 KB) 2010-07-18 21:39

ohnobinki

2010-07-14 04:03

I suppose the best way to fix this is to detect and error upon any include recursion.

syzop

2010-07-14 16:57

I feel like this is indeed not a nice bug, if we can fix this for 3.2.9 that would be nice. I then mean fixing the accidental version of this bug.
It would be hard to fix a non-accidental thing, like if someone created a xx mb config file, or a remote include one which keeps including another url with a slight variation...
But the one mentioned in this bugreport getting fixed, yeah that would be nice. Like by compiling a list of includes already included (or scheduled to include) and not re-including them.
Question of throwing a warning or error comes up, what do you guys think?
The include *.conf would be nice to have without warning or error, or should we discourage it ?

If it takes too much effort for 3.2.9, then I won't delay the release for it though, I mean it's not Release Critical.

warg

2010-07-14 22:42

I agree Syzop, i like the list idea, and i too don't believe it's worth stalling release. I stumbled onto this accidentally, and thought it would be worth the bug.

ohnobinki

2010-07-18 21:09

oh, stupid me, that patch is broken. I meant to test the remote-includes stuff before posting it here. But, if anyone's interested in reviewing what's there that would be very useful. ;-)

ohnobinki

2010-07-18 21:40

I wrote these notes while writing the patch:

> The include *.conf would be nice to have without warning or error, or should we discourage it ?

I think we should give a hard error on that if possible. The only way to avoid giving the user an error is, AFAICT, to pass over an include directive without actually performing the include. I would, as a .conf writer, prefer that an include directive always includes.

Users can easily get around over-general glob expressions by:
1. making a new subdirectory to put all of the non-unrealircd.conf *.conf files. Then use include "conf.d/*.conf";
2. using a somewhat less general glob expression. Such as include "mynet_*.conf";
Both of these options are cleaner than adding more *.conf files into the same directory as unrealircd.conf.

- add_include() and add_remote_include() already had a checks for whether or not a file was included, which silently ignores the doubly-included file. However, this check is too late because load_conf() is always called a line or two before add_include() is called. Also, add_include() and add_rmeote_include() are unable to return an error code to their caller or inform the user of the problem (at least with their current parameter/arugment signatures). And, yet again, I think it makes more sense to put the checks into load_conf() because otherwise there'd be more duplicated code between add_include() and add_remote_include()

I am quite convinced that any cleanups I did in this patch are quite essential:

- For example, to tell a user the filename and line number where the recursion occured, I had to store that info into ConfigItem_include. The asynchronous remote includes code only knows this information when queuing the download. Also, the code that checks if there is recursion requires that add_remote_include() only be called _once_ -- thus the birth of update_remote_include().

- I avoided one opportunity to recursively throw ``const'' around, adding it only when I added/changed parameters and only when no recursive const additions were needed.

- Setting INCLUDE_USED in conf_load() is necessary because add_include() is now called before conf_load() instead of afterwards.

- Perhaps I am abusing ConfigItem_include by putting CPATH ("unrealircd.conf") into it and by using the conf_include to detect recursino. Yet, it seems that the conf_include list is only used during a rehash and that the data stored there is never reused after a rehash is over. That is, ConfigItem_include naturally works for checking things like include recursion.

I am fine with this being called too clean-up-y as long as it has a chance of being added later ;-).

Unanswered question(s) I had after editing the code:

- I see complication in unload_notloaded_includes() and unload_loaded_includes() and load_includes(). Why does conf_include even need to be kept around _after_ the cofiguration is loaded? I think it's only used during rehashing. If it's only needed during rehashing, it seems that the list could be emptied after a rehash is completed. Then the INCLUDE_NOTLOADED and INCLUDE_USED flags could be removed.

syzop

2010-07-19 11:52

I see.

I've rescheduled it for 3.2.10 ;)

2379

ircd

tweak

always

2005-02-28 19:45

2010-07-16 18:43

ron330

normal

acknowledged

none

open

openssl issue: openssl version mismatch

Starting UnrealIRCd
[!!!] OpenSSL version mismatch: compiled for 'OpenSSL 0.9.7c 30 Sep 2003', library is 'OpenSSL 0.9.7c-p1 30 Sep 2003'
[!!!] Header<->library mismatches can make UnrealIRCd *CRASH*! Make sure you don't have multiple versions of openssl or zlib installed (eg: one in /usr and one in /usr/local). And, if you recently upgraded them, be sure to recompile Unreal.
_ _ _ ___________ _____ _
| | | | | |_ _| ___ \/ __ \ | |
| | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| |
| | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` |
| |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |
\___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|
                           v3.2.2b
                     using TRE 0.7.0
                     using OpenSSL 0.9.7c 30 Sep 2003
                     using zlib 1.1.4
my provider has updated the openssl libary and the one for unreal is outta date and it's causing major problems

codemastr

2005-02-28 20:16

Have you tried recompiling Unreal? (make clean && make)

ron330

2005-03-01 03:40

yup still does it i had to disable the ssl to get rid of the message

crazy

2005-03-01 04:26

I know that warning :) (whit openssl and ziplib headers).Don't ask me why but you need to : make clean && ./Config (or ./Config -q) && make

*EDIT *blind* Don't do ./Config -q you have ssl disabled :o just ./Config *EDIT

syzop

2005-03-01 12:46

(I typed a similar msg yesterday, but mantis was down and my browser did not let me resubmit my text)
Well..
'OpenSSL 0.9.7c 30 Sep 2003'
'OpenSSL 0.9.7c-p1 30 Sep 2003'
is not the same, hence the warning.

But *IN THIS PARTICULAR CASE* it is probably a harmless warning because the difference is at patch level (the -p1) there shouldn't be any binary incompatibilities introduced.
Of course, if you get something like 0.9.7c vs 0.9.7d, it's a different story and you should recompile then.
[I know, perhaps we should parse the version thing, but.. blah :P]

ron330

2005-03-01 13:01

yeah that's what i ended up doing was just disabling the sssl till i found out how to fix it right. i'll have to try the make clean && tonight and see if that fixes it.

ohnobinki

2010-07-16 18:43

So... the ``fix'' to this would be ignoring ``-p1'' from ssl's versioning values? Has anyone else ever encountered this problem recently?

From the number of years of no activity on this bug, I think that a change isn't needed.

3931

installing

major

have not tried

2010-07-15 12:34

2010-07-16 15:29

syzop

ohnobinki

normal

resolved

none

fixed

ircd no longer compiles with curl

You (ohnobinki) added a 'does curl work?' check.
However, it does not work properly, it prevents the ircd from compiling with my self-compiled curl. Presumably your trick with LIBS= and such does not work, I think due to c-ares / curl configure order, where the c-ares linker flags are not sufficiently known yet (and not yet in IRCDLIBS).

In any case, I can't use remote includes in CVS now.

If I rip out your check, it works, but you might have a better idea.

1) Have a self compiled curl with c-ares, like by the unreal auto install thingy
2) Try to compile Unreal

checking curl_easy_init() in -L/home/syzop/curl/lib -lcurl -lidn -lssh2 -lssl -lcrypto -lldap -lrt -lssl -lcrypto -lz... no
configure: error: in `/home/syzop/Unreal3.2':
configure: error: You asked for libcURL (remote includes) support, but it can't be found at /home/syzop/curl
See `config.log' for more details.

--

configure:13323: gcc -o conftest -pipe -g -fno-inline -Wall -Wno-strict-aliasing -Wno-unused -Wno-char-subscripts -Wno-format-zero-length -fstack-protector-all -Wstack-protector -DNOCLOSEFD -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -I/home/syzop/curl/include -DUSE_LIBCURL conftest.c -lcrypt -lnsl -lz -L/home/syzop/curl/lib -lcurl -lidn -lssh2 -lssl -lcrypto -lldap -lrt -lssl -lcrypto -lz >&5

missing -lcares and related stuff...

which is logical, as c-ares is not built at that point yet.

guess what, that might be the reason why we didn't have such a 'does curl work' check before ;)

unreal-3931-no-filter-cares.patch (2 KB) 2010-07-16 01:47
unreal-3931-hacky-reorder-configure.patch (3 KB) 2010-07-16 02:15

ohnobinki

2010-07-15 23:40

cURL can't possibly be built against a copy of c-ares that doesn't exist yet. If there is a ./curlinstall script and it wants to link against the same c-ares install that unrealircd will link against, that copy of c-ares must be around before ./curlinstall is run. How else is it even possible for ./curlinstall to be successful otherwise? :-p

I'll reproduce the failure and post again when I have some further thoughts ;-).

ohnobinki

2010-07-16 01:14

OK, the fix is as simple as not filtering out c-ares-specific flags from curl-config's output. When compiling against a properly installed system-libcurl, the filtering makes no difference anyways:

ohnobinki@ohnopublishing ~ $ curl-config --libs
-lcurl
ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/libcurl.so |grep libcares
0x0000000000000001 (NEEDED) Shared library: [libcares.so.2]
ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/libcurl.so |grep RPATH
0x000000000000000f (RPATH) Library rpath: [/usr/lib64]
ohnobinki@ohnopublishing ~ $

Also, having multiple copies of the same c-ares flags shouldn't hurt as only the first copy will take effect.

But... all considered, do I really have to reorder the curl/c-ares configure checks? :-p It sounds like that's the solution you want (and shouldn't be hard).

ohnobinki

2010-07-16 02:20

unreal-3931-no-filter-cares.patch: This does what I want ;-) (except it doesn't go so far as to unbundle cares :-p ).
unreal-3931-hacky-reorder-configure.patch: This is what you wanted, syzop.

syzop

2010-07-16 12:56

We already had the discussion regarding system/self-compiled in 0003888
My post (2nd comment there) explains in clear why we do what in each case, the trade-offs, and the fact that any decision is sub-optimal.

I can copy-paste my entire comment from there, but you better just re-read it.

I have a feeling you can only think like 'MUST use SYSTEM libs in ALL cases, only THEN = teh ok', even though there are clear issues with it, again, mentioned in my comment in 0003888.
It's only safe to use the system libs when using a package manager or something like bsd ports, which upgrade unreal when dependency libs are updated (and are not ABI compatible). But again, now I'm repeating myself, the comment from 0003888.
c-ares has a really bad track record with regards to ABI incompatibility, and curl isn't that great either. OpenSSL on the other hand, has quite a good one. And zlib is really excelent.

Your suggestion to rip out our c-ares and always use system c-ares will therefore cause crashes whenever c-ares decides to break the ABI yet again.
Crashes and things that suddenly make the ircd no longer able to boot are a bad thing IMO, and if we can avoid them, we should.
If your opinion is that such a crash or non-working ircd is fine, and that the user should take care of it "because it's not our fault" (or contact their sysadmin to address the issue), that's fine, that's your opinion and isn't totally weird.
But *I*, I put avoiding crashes and having a working IRCd first, above any "religious-like" thoughts, "100% correctness without having an eye for the rest", whatever, by lack of a better word :P.
EDIT: I just realized that a better comparison would be: pragmatism versus idealism :)

The only remaining case I can see with self-compiled is when it was self-compiled against c-ares X and we now use c-ares Y. This (letting CVS aside) can only happen if you have like done curlinstall in unreal version X, and later re-use it in unreal version Y.
It would be nice if we could detect this, though I don't think we can.
We could warn the user about it, though, I'll do that.
Done:
- Added some checks in ./Config which (often) ensures that the self-compiled
  curl version is new enough and is not using a c-ares which is binary
  incompatible. If the self-compiled curl version is (too) outdated, then we
  now suggest to rename it and have the installer re-download and compile
  it automatically. This avoids some potential crashes.

Then everything as far as self-compiled is covered.
If you screw up anything with system-libs, which is easy as mentioned above, then you're on your own :)

syzop

2010-07-16 12:59

You can commit unreal-3931-hacky-reorder-configure.patch if you want. Just tested it and it fixes things here :)

I could do it, but I don't want to take credit for it...

ohnobinki

2010-07-16 15:29

Fixed using the second patch. Sorry, I didn't intend to break this ;-)

- Support compiling with a bundled c-ares again, the hacky way. (0003931)

3935

installing

trivial

have not tried

2010-07-15 23:49

2010-07-16 14:04

ohnobinki

normal

resolved

CVS

none

3.2.8

fixed

user-friendly `make custommodule' errors

An often-heard question in #unreal-support is how to properly use `make custommodule'. I think that the following output would be more useful:

peter-krakers-mac-mini:unreal zoidberg$ make custommodule m_mymodule
Please set MODULEFILE when calling ``make custommodule''. For example, ``make custommodule MODULEFILE=callerid''.
make: *** [custommodule] Error 1
peter-krakers-mac-mini:unreal zoidberg$

I'm sure that the output could be made cleaner, though. And the patch only supports the simple case of MODULEFILE not being set.

unreal-make-custommodule-error.patch (1 KB) 2010-07-15 23:49

syzop

2010-07-16 13:14

Sounds fine, you can commit the patch for 3.2.9.

ohnobinki

2010-07-16 14:04

- Give more clear error to users who use ``make custommodule'' without MODULEFILE. (0003935)

Thanks.

3930

installing

minor

have not tried

2010-07-15 12:05

2010-07-15 23:35

syzop

ohnobinki

normal

resolved

none

fixed

./configure: line 12887: I: command not found

I don't know what got screwed up, but this is on latest CVS:

checking for syslog... yes
checking for vsyslog... yes
./configure: line 12887: I: command not found
checking for zlib... found in /usr
checking for dlopen... no
checking for dlopen in -ldl... yes

Line 12887 of configure reads:
I IRCDDIR="$withval"

ohnobinki

2010-07-15 23:35

- Remove extraneous `I' from configure.ac, run ./autogen.sh. (0003930)

I accidentally inserted an `I' into line 439 of configure.ac. Sorry for taking so long to notice and fix this.

3933

ircd

tweak

have not tried

2010-07-15 13:09

syzop

normal

new

none

open

Update coders, donators, etc

I shouldn't forget: update the coders, donators, testers, etc etc before 3.2.9 release.

Has to be done by me during the RC's -- no point in doing it before that.

3927

installing

tweak

N/A

2010-07-14 13:03

2010-07-14 23:51

warg

normal

acknowledged

none

3.2.9

open

patch to make --prefix and --bindir work, also adds --ircdname

This patch modifies:
    Config
    configure
    Makefile.in
    unreal.in
    ircdcron/ircdchk.in
    configure.ac
    autoconf/m4/unreal.m4

This patch enables the use of:
    --prefix=PATH
    --bindir=PATH

This patch adds:
    --ircdname=NAME

This patch removes:
    --with-dpath
    --with-spath

This patch also:
    cleans up the --help output, informs the user what the defaults are, eg:
        --with-listen=BYTES Specify the listen backlog value (default: 5)
        --with-bufferpool=NUM Specify the size of the buffer pool (default: 18)
    makes the Config script play nicely with these changes
    fixes 0003926 by warning and preventing the executable path and name from being the same as the unreal script's path and name
    allows for deep pathnames (previously this wasn't possible because BINDIR was a path to a filename and not a directory, ask binki for more info on this)

this patch was designed on cvs for unreal3_2_fixes

new-warg-prefix-bindir-ircdname.patch (540 KB) 2010-07-14 23:51
final-warg-prefix-bindir-ircdname.patch (546 KB) 2010-07-14 13:48

warg

2010-07-14 13:25

please use: final-warg-prefix-bindir-ircdname.patch

this also changes --with-disable-extendedban-stacking to --disable-extendedban-stacking. this makes more sense because we're enabling/disabling a feature, not tweaking settings for a package. technically there's a few more --with-things that should maybe a --enable-thing. *shrug* just an opinion.

ohnobinki

2010-07-14 14:05

Deleted other patches as mantis provides no way to mark them as ``do not use''.

warg

2010-07-14 14:06

Thanks binkmeister

syzop

2010-07-14 14:32

You should have mentioned that:
1) You are renaming the binary to 'unrealircd', or making it the default. This is not what I want, make it 'ircd' again.
2) Not sure what you did with SSL, it's at least not mentioned. Perhaps you could either scratch it, or make more clear that the =DIR is optional and will otherwise be autodetected... something like that... basically document what it does atm.

Other than that, I'd still have to review the idea of this report itself, but I'm not against it.

ohnobinki

2010-07-14 14:37

> 1) You are renaming the binary to 'unrealircd', or making it the default. This is not what I want, make it 'ircd' again.

I think that, to support the standard ``./configure && make && su -c 'make install' '' paradigm, the name of the ircd binary should be renamed. A name as generic as ``/usr/bin/ircd'' cannot be claimed by any ircd project.

Would it be enough to make a symlink from ircd -> unrealircd if the installation is a ``traditional'' instead of system install?

syzop

2010-07-14 16:37

Well, who said I would like to support the standard paradigm you describe :). In fact - and you're well aware of it - I don't, I want people to go through ./Config.

Also, it's not like you are going to run 3 different ircds at the same time if you install it like that...

syzop

2010-07-14 16:45

For consideration in 3.2.10 -- need to think careful about this. Not urgent.

warg

2010-07-14 22:47

Syzop i'll reduce this to have it only enable/use --prefix, --bindir, --ircdname and remove --dpath and --spath, and not touch anything other than necessary to change that. I was bored, and perhaps took too many LARGE steps. I specifically shouldn't have assumed that changing the ircd name is a good idea. I can just leave that up to the end-user instead.

warg

2010-07-14 23:50

NEW: new-warg-prefix-bindir-ircdname.patch
DELETE: final-warg-prefix-bindir-ircdname.patch

default --with-ircdname is ircd

default --prefix is `pwd` (classic)

default --bindir is `pwd`/bin in configure, `pwd`/src in Config (classic) if
   the default is accepted

Config, Makefile.in, unreal.in, ircdcron/ircdchk.in is changed to reflect the
   above changes

I changed Config transparently (to the end-user anyway). The 2nd and 3rd
   questions are still the same, and I simply extract the bindir/ircdname
   from the answer using sed. This is so the end-user isn't confused by an
   unexpected change.

0003926 is still fixed in the exact same way.

Note @ Syzop:

I understand you don't want the typical paradigm, and want people to use Config, but as an long-time Unreal user, I believe the option should be available. Atleast if if works right, we won't have people asking stupid questions when it breaks =). We can still strongly recommend the use of Config, or maybe only support the use of Config. I guess my point is if it exists at all, then it should atleast work properly, and to the end-users expectation.

1507

ircd

feature

N/A

2004-01-24 02:14

2010-07-14 21:27

ace

syzop

normal

resolved

none

fixed

Remote including of MOTD files

It would be nice to be able to remotely ircd.motd, ircd.rules, ...files. There would be a block like:

motds {
motd "ircd.motd";
rules "ircd.rules";
...
};

Something like that. If you want to load an MOTD remotely, you'd simply replace the above with a URL, like http://www.domain.com/ircd.motd [^]

PHANTOm

2004-02-23 13:21

and this feature for tld:: would be even more usefull.

codemastr

2004-02-23 16:55

I'll have to think about this. It definately will not be done until after 3.2 though.

w00t

2004-02-26 18:01

Hm... A web accessible motd... That could raise some quite interesting possibilities for irc stats pages on websites... :)

aquanight

2004-12-01 22:45

>Hm... A web accessible motd... That could raise some quite interesting possibilities for irc stats pages on websites... :)

(Except don't forget that you have to /rehash [-motd] every time you update :-P .)

zEkEsTeR

2004-12-09 23:31

i built a simple perl script to do this, its about time I updated it...
Basically it would download the network MOTD from the network site, merge it with a local MOTD for the individual server, move it to the Unreal dir, connect to the IRCd, oper, and /rehash -motd. Works well, now expanded so it auto-updates, as well as handling other .conf files, as a number of the servers on the network couldn't get curl installed for whatever reason.

aquanight

2004-12-10 12:12

>connect to the IRCd, oper, and /rehash -motd

For the record, you do know you could just sighup the thing? :P

Anyway, it's also not hard for something like services to read MOTD from an http server and SVSMOTD it out to everywhere... but this could be interesting nonetheless.

On another consideration, if a tld from a remote included .conf specifies an motd, where is that motd read from (it might not make sense to read it from the local machine)? (I guess the same can be asked about confs included from a remote include... :o .)

syzop

2006-09-01 05:19

I think we all agree this idea would be nice. Just need to hook someone to implement it ;p. This would be for Unreal3.3*.

When you're at it, see also 0003034 for some talk about specifying default motd/rules files... Even though I'm unsure if it's that useful since you can get the exact same effect by having a tld *@* block (ok almost, exact effect ;P).

djGrrr

2006-09-07 21:15

(ok almost, exact effect ;P). <-- exactly, apparantly remote queries of the motd only return the default ones... and well, adding a tld block just for that is kinda annoying :P

syzop

2010-07-14 21:27

Both specifying default motd/rules files through the files:: block, and now also the remote MOTD/rules/etc thing in CVS (for 3.2.9), are done now.

3055

ircd

feature

always

2006-09-05 06:43

2010-07-14 21:25

syzop

normal

acknowledged

none

ALL

3.3-alpha0

open

Server-side MLOCK support

I'm tossing up a crazy idea.. Server-side MLOCK support.

Services would inform the IRCd (on-netsynch, and on any MLOCK change) of the modes that are mlocked.
For example: SOMEMLOCKCMD #chan sntlk
This would mean the s/n/t/l/k modes may not be changed by users (not +, not -), this COULD mean that for example +sntl 55 is locked and that +k may never be set, or it COULD mean that +sntl 55 somekey is always set. For the IRCd it does not matter what it means (see next).
No paramters would be given, since they are not needed... The MODE is set by services and then locked (or actually, reverse, since that's safest).
*All* the IRCd does is check upon every -mode/+mode by a user, to see if he/she is allowed to change it.

What this would do is fix race conditions, so that you can for example lock +Q and other people cannot -Q. Or for any other mode, really.

Channel owners (+q) would still be able to override the locked modes. So would servers (and services).

In short: services would still need to enforce the locked modes themself (eg: in case of another server merging [netsynch]), like now. But they will get rid of the user race conditions.

Good / Bad? Opinions are welcome, especially by services coders.

Memory-wise this would consume, in Unreal3.3*, one 64 bit var, so 8 bytes per channel. Which is 8K per 1000 channels.
CPU-wise impact is hardly any.

White_Magic

2006-09-05 07:07

this sounds like a perfect answer to the problem, rather than " killing " someone for racing the modes.

djGrrr

2006-09-07 21:31

I really like this idea, and you even thought of everything (Channel owners (+q) would still be able to override the locked modes. So would servers (and services).)

And since it would be for 3.3.* it wouldn't cause any incompatibilities :)

tabrisnet

2006-09-07 21:56

partly disagree. server/services only. don't allow channel owners to do so. if they are able to change the mlock in services, then they have the right to do so, and should not override.

djGrrr

2006-09-07 22:36

i definetly don't agree with you there tabrisnet; what if services is down for some reason (its possible, and can sometimes be for hours at a time) ? then the channel owner can't even change mlocked modes....

tabrisnet

2006-09-07 22:43

and if you have multiple channel "owners" (who have +q), but only one is founder, and only one can change the mlock, what happens there? We now have a way for a co-founder, or non-founder, to bypass something the founder wanted!

djGrrr

2006-09-07 22:45

.... there comes the issue of who do u trust....

tabrisnet

2006-09-07 22:55

Which is often the entire point of +Q. Not trusting the ops to not war with each other. Yes, it shouldn't happen. It does. It happens in real life (assuming anything on IRC is real).

djGrrr

2006-09-07 23:03

ops maybe, but not channel owners (+q), which is what the thread was all about to begin with

Stealth

2006-09-07 23:05

Also, I think when modes are locked on the channel, as with services, only the specified modes should be forced. To lock modes unset, simply specify the -mode as you would with services:

nt-k
Lock +nt, but do not allow +k
All other modes should be settable

tabrisnet

2006-09-07 23:26

Hi. I'm tabris, owner of SurrealChat.net. I have about 200 users, half of which are under the age of 14. Maybe 10% are over 20.
Many of these kids are at the stage where mIRC is cool and scripting is leet. Writing or testing shitlist and war-scripts is a hobby of theirs. Now, to be honest, the founder should take care of this, and if they don't care then it's not an issue. But the fact remains, this does happen, it will happen, and it cannot be stopped short of closing/freezing the channel and removing all chanop status.

Meanwhile, it is not uncommon for +Q to be set by the founder to prevent such chanop wars, but still allowing problem users who are NOT on the channel access list to be removed via !kick.

Yes, You are assuming that users will either be smart or responsible. I'm not. I want a speedbump so 16 y/o Johnny doesn't run over any children in his new Jaguar going 40MPH in the parking lot of the nearby WalMart.

I no longer believe in hte goodness of others. At least not of little children when dealing with other little children.

tabrisnet

2006-09-08 08:37

As to services being down... if services is down [long enough], NO ONE will have +q, as no one will be able to ask chanserv to op them.

syzop

2006-09-08 08:47

IMO +q should be allowed to change it (well and opers with can_override of course, and SAMODE etc, but needless to say that)

But, anyway, as for when services are down.. that's a good point.
I think it should be made that, when services (server defined in set::services-server) are down for more than a certain period of time, then all server-side MLOCKing restrictions should be removed (remove the restriction itself), this can even be made configurable in the unrealircd.conf, and default to - for example - 5 minutes.

tabrisnet

2006-09-08 09:01

Then it will need to be something that is also kept and synched when a netsplit is resolved (I probably said that badly, but the only term I can think of is 'netsplit healing'). Services won't know to reset it otherwise.

syzop

2006-09-08 10:00

Yup (I understand).

brain4

2006-09-09 08:14

what happens if your server side mlock clashes with that of a services (uline) set mlock? Does the uline override the server side mode lock?

Not referring to +q users here of course u:lines are a seperate issue, u:lines should NEVER be allowed to 'lose' at any attempt to do *anything*.

syzop

2006-09-09 09:06

Pretty obvious I think :P

JasonTik

2006-09-09 12:03

Don't U:Lines override pretty much everything anyhow? (Including the current form of server side mlock (restrict-channel-modes, or w/e))

syzop

2006-09-09 13:01

Correct.

Stealth

2006-09-09 14:38

In the even services go down, I think servers should keep the settings... If they are there, then they are wanted, and if they were temp, then there should still be a +q around to undo it

djGrrr

2006-09-09 17:40

I agree with Bugz, i don't really think it should be temp if services splits, could kind of defeat the purpose... and there would most likely still be a +q around

syzop

2006-09-09 17:55

As I said, the time limit would be configurable.

1522

ircd

feature

N/A

2004-02-07 14:52

2010-07-14 21:08

normal

acknowledged

none

Any

open

/rehash all command

Adding the ability to rehash all servers with one line.
This will be pretty usefull when the remote include command will become avaliable.
The way I see this working is a supporting version of unreal linked to a supporting version will pass this line, and supporting linked to unsupporting will pass instructions (remote rehash) for each server behind and including the unsupporting one.
Though this is open for suggestions.

AngryWolf

2004-02-07 18:11

Imagine an IRC network with two server admins (A and B) and five servers. The first admin (A) has only one server, the others are owned by the second one (B). Let's say, "B" made a change in his/her servers and now ready to rehash all of them with a single command (that is, /rehashall or something you are talking about). After done, "A" shouts "Hey! Who the hell rehashed my server? I haven't finished making changes in my conf files!" Now imagine what would happen on much bigger networks. :-) [Just my thoughts.]

syzop

2004-02-09 04:41

[strange I thought I replied to this, ah well.. I guess I didn't hit the button or devel*/my isp was down..]

We COULD consider this... and perhaps only rehash remote includes... I mean, I don't find the idea totally stupid.. I thought about it too when I was on a network with remote includes and X servers, it would be very helpful.

Anyway, currently we are preparing for next release (and thus not really implementing new features), so I'll prolly consider this again at some later stage :).

stskeeps

2007-04-27 06:09

Bump.

crucialstorm

2008-06-22 22:51

I also requested this feature it would be so nice to have since i have 10 ircd accounts

syzop

2010-07-14 21:08

I'll do this for 3.2.9 myself. I could 'assign' it right now, but I'm not yet working on it ;).

3038

ircd

feature

always

2006-08-26 15:23

2010-07-14 21:07

brain4

normal

acknowledged

none

All

3.2.6

open

Bandwidth and resource wastage when changing hostnames

When a user changes their hostname or ident there is a configuration option which allows a the ircd to show the user as parting and rejoining, so clients can stay in sync:

[21:09] <-- Parts: jasont308 (BluFudge@csops.deepspace.org) (Rejoining because of user@host change)
[21:09] --> Joins: jasont308 (BluFudge@ServerAdmin.Stardust.Deepspace.Org)

The problem is that this uses much more bandwidth than neccessary.

Take for example if jasont308 is "visible" to 40 users on 10 channels, this means that 40x10 parts must be sent out, this is 400 part lines to 40 different clients. We must then send 40x10 JOINs, so in total we now have 800 lines of text sent out for one vhost change (even more if you count the 'restoration' of modes if they were opped when they changed hosts).

Instead i propose that the PART is replaced by a QUIT (as the user never actually quits anyway this shouldnt be difficult), taking the number of output lines down to 440 (40x QUIT plus 40x10x JOIN) and saving a LOT of bandwidth in the process:

[21:09] <-- Quits: jasont308 (BluFudge@csops.deepspace.org) (Changing host)
[21:09] --> Joins: jasont308 (BluFudge@ServerAdmin.Stardust.Deepspace.Org)

Change hosts with the required option enabled.

aquanight

2006-08-26 15:28

Only true if all 40 people were on the same server.

brain4

2006-08-26 15:38

If you have remote users, the remote users STILL see parts and joins, they'll act upon the CHGHOST ;)

Stealth

2006-08-26 15:56

I don't like this idea... if you honestly had an issue with bandwidth, then don't use the feature. Clients really ony desynch if they are crappy and don't check/update their info when people talk

brain4

2006-08-26 15:57

That's not the point.

Every other ircd with this feature uses QUITs because of this very reason, it is an issue...

Trocotronic

2006-08-27 07:21

PART is long about ~64bytes. Imagine that channel has 100 users (medium network). That's 6400bytes (~6.4kb). JOIN is less than PART, but we assume is 64bytes long too. So, server sends <12.8kb. On a worse case for a server connection which is 30kb/s for upload, this amount of data would be sent in 3/5seconds=0.4s=4ds. Do you think that's really a big wastage of bandwith?
If you don't like math, I'd like to add QUIT could causes confusion on users. "Hey jasont308, why do you quit? Am I boring you?".

brain4

2006-08-27 07:30

"Hey jasont308, why did you *PART*? am i boring you?" :p

Quit is also shorter (text wise) than Part, as it doesnt have a channel name in its parameters. So even the one QUIT message is shorter than a single PART message, but the point is you have to send X number of part messages, and you have to do this for every channel the user is on, where you only ever have to send ONE quit!

Speaking of which, PART also has the issue that it probably wont update the hosts of users in private message chats... dont quote me on that.

aquanight

2006-08-27 18:38

Makes me wish the RFC people didn't veto the idea of doing JOIN or PART with multiple channels (server->client). Would save even more bandwidth if you could do :who QUIT blah\n:who JOIN #one,#two,#three,#four,#five,#six,#seven,#etc

btw: possible reason for using PART over QUIT: clients with notify might try to be too smart and signal a signoff when the user didn't really sign off. PART at least doesn't trip clients to signal a signoff so they wait until they get a numeric (WATCH) saying so.

[edit: curse you mantis!]

Stealth

2006-08-27 22:26

> "Hey jasont308, why did you *PART*? am i boring you?"

"Hey jasont308, why did you *QUIT*? am i boring you?"
"Hey jasont308, can I have access to some of your hosts?"
"Hey jasont308, are you really an FBI agent?"
(in help chan) "Hey, I think jasont308 uses open bouncers!"

Let's just say that was a bad example...

syzop

2006-09-09 07:34

While you (brain4) are right about the saving of bandwidth, I don't like the idea for other reasons.
The rejoin stuff already isn't too nice, but it's acceptable. The quit thing on the other hand, is a lot worse in my eyes, causing confusion to both clients and users, since it really looks like the user reconnected.

In my opinion the "correctness" or "visibility" or whatever-you-call-it argument should prevail over the bandwidth argument in this case.

Anyway...... Since it can be a significant decrease in bandwidth (~40% on avg), I think I'll make it an option regardless of what my opinions are. So a network could opt for quit.

syzop

2006-09-19 17:42

acknowledged as to-be-done, but not assigned. so no ETA.

penna

2006-09-20 04:53

Well ircu uses quit/join and not part/join and I don't think that quit/join confuses more then part/join.

3168

ircd

tweak

N/A

2006-12-28 09:47

2010-07-14 20:58

syzop

normal

resolved

none

ANY

3.2.6

fixed

(re)move timesynch errors

remove timesynch errors/warnings from 'errors' loglevel to it's own category, or remove it altogether.

People are idiots. The reason for this change.

Additionally, add a >somebigyear check, against people with bogus ircd.tune's.

When we're at it, add code to check for last TStime() vs current TStime() and ircd_log() and sendto_realops() when this value changes heavily. Basically, not too different than eggdrop :). That way at least some users will see why everything will hang or screw everything up due to a heavy time change.

syzop

2010-07-14 20:58

The timesynch errors/warning were improved in CVS for 3.2.9, and time jump detection was added in 3.2.8. This bug can be closed

3134

ircd

feature

always

2006-12-04 14:20

2010-07-14 17:49

syzop

normal

acknowledged

none

ALL

3.3-alpha0

open

Automatic suffix on loadmodule

Instead of:
loadmodule "modules/blah.dll";
it should become:
loadmodule "modules/blah";
(it will add .dll for windows, and .so for *NIX, etc)

Additionally, let the make process add a symlink called 'modules' pointing to 'src/modules', so we can make it all loadmodule "modules/etcc" instead of src/modules for half of the *NIX installs (not all..), and modules/ for win32 :P

Easy to do, but useful and will make it easier for users switching between installation type's (and OS's). Additionally, it looks nicer as well (mainly the all-will-have 'modules/' thing)

3173

module

feature

always

2006-12-28 14:04

2010-07-14 17:49

syzop

normal

acknowledged

none

ANY

3.3-alpha0

open

Make extban modules non-PERM

Make it so extbans modules can be reloaded and unloaded. So they don't need to be PERManent anymore.

This only requires some "remember this extban type until all modules are loaded again" and a "remove any extban types that no longer have a handler/module" thingy.

2882

ircd

feature

always

2006-04-13 14:47

2010-07-14 17:49

Trocotronic

normal

acknowledged

none

AMD K6 32bits

Windows XP Professional

SP2

3.2.5

open

Configurable CASEMAPPING (Lower/Uppercase with charsets)

I know that charsets for diferent languages is very complex.
I have loaded spanish and catalan charsets.
For example, á is lowercase of Á. So, eáe and eÁe are the same word.
Yes, to distinguish lower and upper letters for every charset sounds too waste. But I think it could be possible.

Locedit.zip (349 KB) 2006-06-11 09:18
unreal.3.2.5-locale.tar.gz (8 KB) 2006-06-05 03:35
locedit-fixed.rar (245 KB) 2006-06-11 12:38

Stealth

2006-04-13 19:03

This has been mentioned many times, and will not be fixed. It even describes this in the documentation:

[quote]NOTE 2: Casemapping (if a certain lowercase character belongs to an upper one) is done according to US-ASCII, this means that o" and O" are not recognized as 'the same character' and hence someone can have a nick with B"ar and someone else BA"r at the same time. This is a limitation of the current system and IRCd standards that cannot be solved anytime soon. People should be aware of this limitation. Note that this limitation has always also been applied to channels, in which nearly all characters were always permitted and US-ASCII casemapping was always performed.[/quote]

Trocotronic

2006-04-13 19:18

Standards, standards, standards... the better improve of unreal is its non-standaring.
You will agree with me that if unreal supports or enchances this feature, will be a better ircd.
Why cannot you break this rule? Is there any special reason for accept US-ASCII as the unique alternative?

Bock

2006-04-19 08:05

/me send patch to syzop about it. He say, that at 3.3 maybe it be.

Trocotronic

2006-04-20 16:10

Bock, could you upload your patch, please?
Thank you.

Spider84

2006-05-19 12:10

ftp://ftp.bynets.org/sources/unreal3.2.4-bynets.diff [^]
this patch add support of different locales in file mode.
You can change locale without server rebuild, just by rehash command.

Bock

2006-05-19 16:16

yep, this is it.
I hope, that this patch will be in 3.3*.
On our network for 180 days never be bug or crash server with this patch.

Bock

2006-06-05 03:35

It's clean version of patch to current version cvs (2006-06-05). Fixes trouble for Russian and Belarussian lower/upper issues. Read reame.txt in locale/ for your locale.
PS: It worked on our network (ByNets) since 2006-02 and no bugs/crash not found.

Bock

2006-06-11 09:10

I added file (Locedit.zip) which conteins GUI editor for locales, patch for current unrealircd (3.2.5-rc3) and directory with locales.
For example you may view to belarussian-w1251 or russian-w1251 files for understanding principle.
Author (Killer{R} - support@killprog.com)) say, that trouble will be (maybe) with multibyte codes (files), but if it be, he may to correct this (chinese for example).
It fixes trouble with namechannels too. Advantage of this patch - add and reload locales file without recompilation and restarting ircd, only rehash.
Since 02.2006 - no errors, crashes, etc.
See you :]

Bock

2006-06-11 12:38

The fixed version of locedit (supported multibyte too) with sources.

avenger

2006-06-13 08:30

Note that the patch posted by Spider84 not only adds a support for the locale accents uppercase matching, but add new modules (with other totally unrelated functions), and some ByNets-specific thingies. :)

Bock

2006-06-13 09:23

2 avenger - yes, it's patch to our network, clean version is listed below. :]

syzop

2006-11-01 07:49

I've linked a couple of bugids to this one.
Renamed this title to 'Configurable CASEMAPPING (Lower/Uppercase with charsets)', since that's what it is...

What is CASEMAPPING? CASEMAPPING decides which characters "belong to each others", or in other words... which upcase character belong to which lowcase character.
http://www.irc.org/tech_docs/005.html [^] ctrl+f CASEMAPPING
We currently always use 'ascii', which is what everyone is familiar with I guess.

The idea is to make this a configurable option in the conf to set it to an alternative CASEMAPPING. This one will then be used, and will be properly announced in 005 etc.
What are the limitations?
You can only have ONE casemapping configured (eg 'ascii' or 'some-latin1-thingy'. You cannot do casemapping for both a russian charset, an hebrew charset, and some eastern european charset... Why not? Because the same character mean different things in each charset. This is why bug 0002987 was closed, because some people don't seem to understand that.

What IS possible?
It's possible to configure a different CASEMAPPING, for example iso8859-1 (latin1), this will then be used for comparing if things are "the same", such as nicks and channels.
This COULD also be used by something like spamfilter (basically any strcasecmp/stricmp in our code) which can be open to debate whether that's a good idea or bad (I currently don't see how it could be bad, but perhaps someone can tell). I don't know if TRE supports it, but it would make sense if it would.

As for which technique to use, I haven't looked into it. So maybe it could be discussed here... Something like setlocale() seems to make most sense? What are the disadvantages/advantages of each approach?

syzop

2006-11-01 07:56

When we're at it, it's worth mentioning that in some character sets like russian, some characters like the 'a' will look very similar (or exactly the same) like the latin (western) 'a'. Not sure if something like that could also be resolved, and if we should even bother to do so... Some people argue that should be handled client-side. There have been written various papers on this, see also the discussion 1/2/3 years back when international domain names where introduced.

It's not that differently than 'l' vs 'I', and such things, which look very similar in some fonts like Fixedsys, and I haven't ever heard someone talking about comparing 'l' as if it was equal to 'I' :P. Then again, they still look *similar* and not 100% *equal* :P. Again, is that our problem, or is it the problem of the client / font / etc?

Bock

2006-11-01 11:14

For my opinion, some letters edentical (for ex. russian: "e, T, P(it's "R" russian), A, B (like "V" russian), O, and etc.etc.etc) and now many fonts not look different for different language (I see only in some *nix system, on windows system - verdana, fixedys, lucida console etc.: no different of language). Some letters in BIG (like B) looks like big letter V (russian), but little - no.
In patch, that I send you, and locedit-fixed.rar - you can create file of locale (now present russian, belorussian, maybe now will be ukranian) with casemappping AND resolving trouble with similar letters. I want to find people from other countries to make files locales.
1 year our network works with this patch and it work fine. Peoples, who find me about this and who testing it - noone bad report or so...Only gratitude..
If you don't agree with it - from patch you can take idea about add locales file to ircd without recompiling AND restarting ircd (it's about dynamical add language to ircd).

About badwords and spamfilter... To this question. If people start spamming, usual they don't change CaseSensitive and spamfilter works fine (I'm about russian spam or "happy letters").

[quote]
It's not that differently than 'l' vs 'I', and such things, which look very similar in some fonts like Fixedsys, and I haven't ever heard someone talking about comparing 'l' as if it was equal to 'I' :P. [/quote]
If I give to you see "E" and "A" russian, you don't see differents :]

Bock

2006-11-04 14:24

hm.. I think, that in frases about ONLY CASEMAPPING reason..

3284

module

feature

always

2007-04-18 05:48

2010-07-14 17:49

stskeeps

normal

acknowledged

none

All

3.3-alpha0

open

3rd Party Module Wishlist

This is a parent for the bug reports that would be more suitable for being 3rd party modules instead of core functionality, but won't be included into stable for now.

stskeeps

2007-04-18 05:50

Contact me on IRC if you see something that you think should be added.

djGrrr

2007-04-19 09:44

i think most people kinda want this to be more or less official modules maintained by the unreal coders, but not be included in commands.so, so they can be loaded if wanted. Having to rely on a 3rd party to maintain the modules often just ends up in modules not being properly maintained

stskeeps

2007-04-19 17:53

Admittedly, but it would be nice to get some people involved and then we might include them in core :P See it as a kind of ideas list for modules?

3291

ircd

feature

N/A

2007-04-22 13:23

2010-07-14 17:49

local8

normal

acknowledged

N/A

none

N/A

3.2

open

[Feature/request] View channels in /whowas

Apologies if it was already suggested. My small search didn't reveal anything. I'd like to suggest the ability to see what channels a client was in. So a /whowas local8 would return something like: local8 was ident@host gecos; local8 was on server at time; local8 was in #channel1, #channel2, #etc. One of our past network coders had added in that ability, and with later versions coming out, it might be nice to have it professionally coded in from the beginning. Other thoughts?

N/A

It appears the code was added in client exitings, and nickname changes. Any place the add_history() function was called.

Bricker

2007-04-22 20:35

i dont like this much, as the output would just be ugly, and it would take up that much more RAM, and to keep up with that information i believe would increase cpu usage as well. Maybe im wrong, anyone else?

Bricker

2007-04-22 20:36

should also note, that if the channel was in, say 20 channels, well OMG

Stealth

2007-04-23 00:27

Oh yes, let's break a standard message...

<- :server 314 you nick ident host * :real name
<- :server 312 you nick server :signoff time

There is nowhere in those numerics to add a multi-parameter list. You'd need to create a new numeric for this purpose.

local8

2007-04-23 05:17

The numeric would be the channel whois numeric, just as the server, 312, is the server whois numeric:

314 local8 dave id host * :If I ever develope Thanatophobia, kill me.
312 local8 dave unreal.server :Mon Apr 23 03:11:13 2007
319 local8 dave :#channel20 #channel19 #channel18 #channel17 #channel16 #channel15 #channel14 #channel13 #channel12 #channel11 #channel10 #channel9 #channel8 #channel7 #channel6 #channel5 #channel4 #channel3 #channel2 #channel1

The only concern would be memory and usage. If most people limit channel to 20, what drawbacks would that be memory wise, 20 channels, for...200 users? The nickname history would just fill up quicker, and a nick that was online 2 hours ago might not return anything.

stskeeps

2007-04-24 05:59

I honestly think this would be better for a service, as it can handle the data load a lot more, perhaps connect to a DB.

stskeeps

2007-04-26 06:12

Acknowledged, but I think it should be in a 3rd party service/module.

Stealth

2007-04-26 13:50

Perhaps to make it possible to write a module that does not require people releasing their own version of WHOWAS, we should add a hook for before RPL_ENDOFWHOWAS is sent. This would make it possible for people to add their own replies to WHOWAS, such as a channels list

3848

installing

minor

always

2009-05-21 16:51

2010-07-14 17:28

HotFusionMan

normal

confirmed

3.2.8.1

none

Windows

2003

3.2.8

open

installer should disallow choosing encrypted certificate if "install as service" is selected

Seeing as it's in the FAQ that you can't run the SSL version as a service on Windows with an encrypted certificate, the installer should prevent you from choosing that combination of options.

If "install as service" is selected, grey out the "encrypted certificate" option.

syzop

2010-07-14 17:28

If this is possible to do in the installer, and it's an easy fix (should be??), then: yes, definitely! We've had quite some support requests due to users configuring it this way...

3702

ircd

minor

always

2008-06-16 00:04

2010-07-14 17:26

Bricker

normal

acknowledged

none

fuckoff

srsly

3.2.9

open

cannot rejoin +O channel on relink ifnot +o

basically, a user would be kicked out and/or not let back into a channel that is +O on a relink (after a netsplit). If they were in there for some other reason, like sajoined, they can be let back in, but maybe the person didnt remember them being in there etc. etc etc...

Jobe1986

2008-06-19 15:38

The point of channel mode +O is so that users without USER mode +o cannot join by themselves. There shouldn't be any way to bypass that without an opers assistance anyway.

So to be honest I cant see how this could be considered a bug but that's just my opinion. If there is a way then its because you wasn't very clear with your explanation.

The problem I see with doing anything about it is you open up the possibility for abuse by users to bypass channel mode +O when they shouldn't be allowed to.

Bricker

2008-06-19 16:07

Jobe: "If they were in there for some other reason, like sajoined, they can be let back in, but maybe the person didnt remember them being in there etc. etc etc..." how unclear was that?

If the user was SAJOINED into the channel but for whatever reason, someone(s) forgot said user was in the channel, they should be kicked out. ie, on reconnect all servers should enforce the modes to kick the user out etc

w00t

2008-06-23 14:26

Getting past it via netsplit is pretty trivial.

Server is started, user connects, joins channel, server linked to network where channel is +O - user has bypassed +O.

This is what no create on split is designed to solve (generically, and without bypass).

syzop

2008-08-10 18:40

Hm, not entirely sure if I'd want this.

We did it for +z (kick insecure users out on resynch), which was a special case... +z is holy ;)
I understand your (Bricker) point, though.

We can see, however, that the TS is newer on the bypassing side, so we could take action on that..

Still... I get a feeling we are getting at uncomfortable terrain then :P

I'm throwing it away from 3.2* for now.

Bricker

2010-04-03 19:54

Bump

syzop

2010-07-14 17:20

we could do this if we are not doing a 'merge' but have different TS's. Otherwise, don't.

Perhaps something for 3.2.10

3868

ircd

minor

always

2009-10-01 19:06

2010-07-14 17:25

ericoc

normal

new

3.2.8.1

none

x86

Linux

Arch Linux

3.2.8

open

Failed server link connection notices are impossible to hide.

I've setup a mesh link configuration in line with http://www.x-tab.org/unreal.html#meshlink [^] .

Since it's mesh, all of the servers have autoconnect; link blocks to one another. The problem is that if a single server in the network goes down, all of the other active servers send non-stop connection attempt notices (similar to the ones below) to all of the opers.

07:25 [NeoturbineNET] !eric.neoturbine.net *** Notice -- Connecting to
          eli.neoturbine.net[eli.neoturbine.net].
07:25 [NeoturbineNET] !eric.neoturbine.net *** Notice -- No response from
          eli.neoturbine.net, closing link
07:26 [NeoturbineNET] !eric.neoturbine.net *** Global -- from
          beastlyfingers.intheskywithdiamonds.net: No response from
          eli.neoturbine.net, closing link

Even turning of all snomasks (/mode eric -s) does not hide the notices.

1. Setup two or more servers linked together (three would be good to see just how many notices are sent) in the mesh topology described at http://www.x-tab.org/unreal.html#meshlink [^] .
2. Oper up on any one of the servers.
3. Split any one of the servers; simply turning off Unreal is fine.
4. Watch the two working servers send continuous notices every few seconds (whatever's specified in connfreq; I'm guessing?)
5. Turn all snomasks off (/mode yournick -s) and the notices will still be sent to you.

The only way I see to get rid of this is to not be oper'd up if you don't need to be or to JUPE the server with something like Anope, but I don't think that the real server can re-link to the network when it comes back online if there's a JUPE in place.

irssi.png (83 KB) 2009-10-01 19:06
unrealircd-3.2.9-CONNECT-snomask.patch (5 KB) 2009-10-31 21:22
unrealircd-3.2.9-CONNECT-snomask-1.patch (6 KB) 2009-11-01 20:36

ericoc

2009-11-01 02:51

I tested the patch and I stopped seeing my own server's failed link notices when I turned off the new C snomask with /mode eric +s -C

I still see all of the failed link notices from other servers on the network though.

I applied the patch to another server on the network, but I still saw that server's failed link notices as an oper on my own server.

Thanks ohnobinki, I know you're still working on this... :)

ohnobinki

2009-11-01 20:23

ericoc, for the servers which you applied the first patch to, you may apply the short upgrade patch at http://ohnopublishing.net/gitweb/unrealircd.ohno.git?a=commitdiff_plain;h=f0aecf547a40c826304aa993083f4a7ae78c68c0 [^] .

I'm going to repost another patch which includes documentation changes soon.

ericoc

2009-11-02 01:55

Well... I tried with the short patch first and was having odd results, so I ended up just killing the installs (saving the configs) and going from scratch with the full patch you offered.

Now, I'm only seeing my own server's link failed notices with the C snomask.
If I turn snomask C off, I stop getting the link failed notices that my own server sends.

I'm not seeing any failed link notices from other servers on the network whether snomask C is on or off.
I'm also not getting the failed link notices from another server on the network that I applied the patch to either.

ohnobinki

2009-11-03 02:44

> I'm not seeing any failed link notices from other servers on the network whether snomask C is on or off.
I'm very positive that my patch should not affect that case when these link failed notices are originating at non-patched servers. If you're on a non-patched server, you should not be able to recieve the messages from the patched server because the server you're opered up on needs to recognize the C snomask.

> I'm also not getting the failed link notices from another server on the network that I applied the patch to either.
Did you get these before? All of the functions I converted except for the ``No response from %s, closing link'' message are only sent to opers locally connected to the server AFAIK. If this message fails to make it from one patched server to another, then I need someone to explain why this happens because I can't find such a situation in the source code.

syzop

2010-07-14 17:25

Aren't these errors just too important to evade?

Not that I'm against putting them in a snomask per-se, but..

Anyway, not for 3.2.9...

3897

ircd

minor

always

2010-03-28 07:29

2010-07-14 17:23

CuleX

normal

acknowledged

none

3.2.8

open

OperOverride through +m unreported

Opers with the can_override flag can override +m and talk, but those actions won't result in a message to any Snomasks or anything like that.

Though it might be spammy on some networks, I think +m override should be reported anyway, possibly as a setting if people are trigger-happy.

- Be an oper with can_override.
- Join any channel with +m.
- Make sure you have no special status (No +vhoaq on you).
- Talk.
- Notice that you have overriden +m, but there was no message to Snomask +e, or any other for that matter.

driew

2010-04-03 11:37

I think this is somewhat funny, since CuleX, you probably got this idea because of me, overriding in a "supposed to be silent" IRC game ^^
If not, you should pm me and tell me what gave you the idea ;)

Regardless, this would be WAYY to spammy for common networks. And I see no point in seeing when other opers are overriding a +m.

It's not like it's the end of the world that an IRCop is overriding +m anyway; I would even go as far as to say, any globop without can_override; should be able to override +m.

syzop

2010-07-14 17:23

Sounds like a bad idea to me.

But! As you said, perhaps some networks would like this, so I'll keep the bugitem. If anyone makes a patch for it that makes this configurable and defaults to off, I can check it in.

Post-3.2.9.

3900

ircd

feature

have not tried

2010-04-04 10:13

2010-07-14 17:18

driew

normal

new

Unreal3.2.8.1 build 1.1.1.1.2.26

none

Linux

CentOS

5.3

3.2.8

open

UHNAMES following HTM

This has a lot to do with the following bug:
http://bugs.unrealircd.org/view.php?id=3885 [^]

But, would it break clients to disable the extended names reply while in HTM?
I only wonder, if once a client says PROTCTL UHNAMES, that if not giving UHNAMES if that's a violation of the protocol, of which you couldn't do this.

It's extremely trivial to make it do this, I just don't know the consequence of doing so.

Otherwise, I would suspect this would be very beneficial to disable while in HTM and return the old style names reply.

I know there are times while on my network, I've had to enable htm temporarily to get a link to sync up while bandwidth is extremely limited. Since there seems to be many clients using auto /who's on users and channels to check away statuses and whatnot. Which can be bad during a rare, but sucky situation when two slow-link/high-latency hubs are trying to sync together. (such as links between the US and the EU)

Line 209 of m_names.c:
                if (!uhnames) {
                        s = acptr->name;
                } else {
                        strlcpy(nuhBuffer,
                                make_nick_user_host(acptr->name, acptr->user->username, GetHost(acptr)),
                                bufLen + 1);
                        s = nuhBuffer;
                }

Could be:
                if (lifesux || !uhnames) {
                        s = acptr->name;
                } else {
                        strlcpy(nuhBuffer,
                                make_nick_user_host(acptr->name, acptr->user->username, GetHost(acptr)),
                                bufLen + 1);
                        s = nuhBuffer;
                }

syzop

2010-04-10 19:44

Sounds good.
In addition to that, I think we should disable /WHO during HTM (it only seems to limit '/WHO *' at the moment).
As WHO is really one of the most floody commands out there (2nd after LIST).

I think the clients will do fine, even though it might violate some spec...
Anyway, HTM means "I'm really short of bandwidth", so such consequences would be justified (like clients not having a fully up to date IAL due to not receiving UHNAMES and WHO)

driew

2010-04-14 12:28

Also, I don't know if this has been reported in the past.. but I think HTM should have an outgoing trigger along with the incoming.

Without looking at the code, I don't know how complex it would be to add that.
But if we go with disabling /who, /list, and using short /names replies during HTM, the server should also know when it's reaching it's outgoing limit just as much as it's incoming.

Though I think HTM was originally designed to prevent 100% cpu situations under incoming floods; but it could be adapted very well to handle both aspects of "I have no bandwidth left..". Since the results of running out of outgoing bandwidth is very ugly, nearly as ugly as the ircd getting swapped out ;)

3915

ircd

feature

N/A

2010-07-02 10:08

2010-07-14 17:18

syzop

normal

new

none

open

Unreal3.2.10 TODO

Parent bug for TODO's for 3.2.10 (or whatever it will be called)

Right now it's purpose is to make clear which requests will not be done in 3.2.9, but possibly in .10.

syzop

2010-07-02 10:22

Also go through 0003049 (3.3 suggestions/features):
1) see what can be backported (also go through 3.3* changelog)
2) see what can be done what was originally scheduled for 3.3*

3358

ircd

minor

always

2007-05-22 11:38

2010-07-14 17:16

Mareo

normal

acknowledged

none

i386

GNU/Linux (Debian)

2.6.18

3.2.6

open

missings operoverride notices

Hello !
chanops and chanadmins cannot set chanmode +L
chanops set chanmode +N

if an oper set mode +NL as chanop or +L as chanadmin, there is no OperOverride notice.

Mareo

2007-05-23 07:42

There is a little error, sorry -_-'

Is not chanmode +N but chanmode +u

About +N, if an oper change his nick in a +N channel, there is no oper override notice

driew

2010-04-15 12:15

As for the nick change in +N; that would be very spammy and annoying.
Just like how I saw a report that there is no oper_override notice for opers talking in a +m channel without voice.. how annoying would that be for other opers?
It just doesn't make sense.

The +u +L notice however, should be fixed. It's probably like that due to the hacks behind operoverride..

syzop

2010-07-14 17:16

while I don't fully understand what exactly is the bug, I presume that setting one or more of the modes mentioned should create an operoverride notice and currently does not.
That is something that should be fixed, as we don't want an oper to silently do things like that ;P.

-> for 3.2.9, but not Release Critical.

PS: these bugs are always hard to fix, and often create another one, so if someone else than me does this, be careful with it ! (well, if I do it myself, I should be careful too ;pp)

1756

ircd

major

always

2004-04-23 15:51

2010-07-14 17:10

syzop

normal

feedback

none

3.3-alpha0

open

*** Notice -- Overflowed unzipbuf increase UNZIP_BUFFER_SIZE

[19:01] <Jedi> for some reason we are getting these messages on all of our servers but not at the same time [14:37] -server.server.server- *** Notice -- Overflowed unzipbuf increase UNZIP_BUFFER_SIZE
[19:01] <Jedi> just out of the blue
[..]
[19:02] <Jedi> rest of it is [14:37] *** Notice -- inflate() error: * Are you perhaps linking zipped with non-zipped? *
[19:02] <Jedi> [14:37] *** Notice -- inflate() error(-3): invalid literal/length code
[19:02] <Jedi> [14:37] *** Notice -- Hint: link::options::zip should be the same at both sides (either both disabled or both enabled)
[19:02] <Jedi> then it disconnects
[19:02] <Jedi> then relinks
[19:03] <Stskeeps> hmmm.
[19:03] <Stskeeps> 3.2-rc2?
[19:03] <Jedi> yea
[19:03] <Jedi> Unreal3.2-RC2fix.

IF I read the code well then this happends it stuff is compressed "too good".
** snip zip.c: **
/*
* On an hybrid test net, we kept filling up unzipbuf
* original was 4*ZIP_BUFFER_SIZE
*
* -Dianora
*/
#define UNZIP_BUFFER_SIZE 6 * ZIP_BUFFER_SIZE

Perhaps it's a good idea to up this a bit, like to 9 *.. (yes we are talking about 6*16k here.. but it's only for (zipped) server<->server links, so... :).

I've asked the guy to change it to 9 *, we'll see how it goes.

syzop

2004-04-23 23:25

post-3.2.

looks like hybrid uses some kind of loop instead of a error/warn... that would obviously be much better. Will take a look at that after 3.2 :).

stskeeps

2007-04-27 05:49

Still an issue?

Bock

2007-04-27 06:10

this error I never don't see.
3.2-RC? and zlib must be 1.2.3. imho

syzop

2010-07-14 17:10

-> 3.3. This pretty much never happens on 3.2.x - I haven't seen it since 3.2.8 at least when we bumped the value.

3357

ircd

major

N/A

2007-05-22 05:15

2010-07-14 17:08

stskeeps

normal

acknowledged

none

All

3.2.6

open

Exiting ssl client [@88.68.55.179.1025]: SSL_write(): OpenSSL functions requested a read()

Why do we exit people based on this? It should just ignore it and let the ircd_SSL_read go ahead in next I/O loop iteration?

syzop

2010-07-14 17:08

This is probably fixed in http://cvsweb.unrealircd.com/cgi-bin/cvsweb/unreal/src/Attic/ssl.c.diff?r1=1.1.2.57.2.10;r2=1.1.2.57.2.11 [^]
[= CVS between 3.2.8.1 and 3.2.9]
Question is, how do we check this ;)

3926

installing

minor

always

2010-07-14 04:01

2010-07-14 17:01

warg

normal

new

none

3.2.9

open

unreal script and binary conflict

when user answers <somepath> for dpath and <somepath>/unreal for spath in the Config script, the result is a unreal script that calls itself because the script has replaced the binary.

it is not unrealistic to think the user would do this.

possible fixes i can think of:
1) renamed unreal to unrealrc (user is less likely to name his binary this)
2) ask for binary name only in Config, and install it to <dpath>/bin/<binaryname>
3) disallow answering with <dpath>/<scriptname>

i think #1 is the easiest way to fix this

[warg@beorn unreal]$ ./unreal start
Starting UnrealIRCd
Usage: unreal start|stop|rehash|restart|mkpasswd|version|gencloak
Possible error encountered (IRCd seemingly not started)
=====================================================
Check above for possible errors, and this output of
ircd.log. If you cannot solve the problem, read
Unreal.nfo on where to get support
=====================================================
tail: cannot open `/home/warg/test/unreal/ircd.log' for reading: No such file or directory

run ./Config

when it asks:
What directory are all the server configuration files in?

answer /<yourhomepath>/ircd

when it asks:
What is the path to the ircd binary including the name of the binary?

answer /<yourhomepath>/ircd/unreal

syzop

2010-07-14 17:01

definitely not 1, you don't want to break such things in a 3.2.x release.

I guess with 0003927 this can also be done.

Not urgent, not needed for 3.2.9, though if someone wants to create an interim fix which does option 2, sure...

3917

ircd

minor

always

2010-07-09 09:18

2010-07-14 00:39

normal

confirmed

none

Linux

Debian

5.0

3.2.8

open

set::modes-on-oper doesn't support negative/removing modes

hello,

for set::modes-on-oper the combination of adding AND removing several usermodes doesn't work.

i combined module privdeaf with unreal3.2.8.1.
first i set in unrealircd.conf set::modes-on-connect +D.
the setting for set::modes-on-oper are +xwWgs-D.
on doing /oper I get operator status, but ircd doesn't remove umode D (combining + and - in set::modes-on-oper doesn't work).

ohnobinki

2010-07-14 00:38

Negative modes in modes-on-oper don't work at all. The following should fail as well:
set::modes-on-oper "-D";

3924

ircd

feature

N/A

2010-07-12 13:23

warg

normal

new

none

open

alias multiple commands

The ability to execute multiple commands via an alias block.

<+henk> Muffin: can you give a concrete example of what you're trying to do?
<+Muffin> Sure
<+Muffin> The example I've been using is a "/sahop" command
<+Muffin> I already have an alias on my client, but a server-side one would be nice
<+seraphim> so a simply rejoin?
<+Muffin> One that executes /sapart $1- and then /sajoin $1-
<+seraphim> *simple
<+seraphim> hmm...
<@warg> frustrating me that i can't do that with a server-side alias :P

3918

installing

block

always

2010-07-09 16:07

2010-07-09 19:47

therock247uk

ohnobinki

normal

resolved

latest cvs

none

Windows

rtm

3.2.9

fixed

unable to compile under windows

Setting environment for using Microsoft Visual Studio 2008 x86 tools.

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC>cd C:\Users\therock247uk\D
esktop\Unr3.2-20100708\Unreal3.2

C:\Users\therock247uk\Desktop\Unr3.2-20100708\Unreal3.2>nmake -f makefile.win32

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

        cl src/win32/config.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

config.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:config.exe
config.obj
        cl /MT /Zi /J /I ./INCLUDE /I ./INCLUDE/WIN32/ARES /Fosrc/ /nologo
/D FD_SETSIZE=16384 /D NOSPOOF=1 /c /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONST
DC_NO_DEPRECATE /D _USE_32BIT_TIME_T src/win32/unreal.c
unreal.c
        rc /l 0x409 /fosrc/win32/unreal.res /i ./include /i ./src /d NDEBUG src
/win32/unreal.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
Copyright (C) Microsoft Corporation. All rights reserved.

        link advapi32.lib src/unreal.obj src/win32/unreal.res
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

        cl /MD /Zi /J /I ./INCLUDE /I ./INCLUDE/WIN32/ARES /Fosrc/ /nologo
/D FD_SETSIZE=16384 /D NOSPOOF=1 /c /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONST
DC_NO_DEPRECATE /D _USE_32BIT_TIME_T src/channel.c
channel.c
        cl /MD /Zi /J /I ./INCLUDE /I ./INCLUDE/WIN32/ARES /Fosrc/ /nologo
/D FD_SETSIZE=16384 /D NOSPOOF=1 /c /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONST
DC_NO_DEPRECATE /D _USE_32BIT_TIME_T src/send.c
send.c
        cl /MD /Zi /J /I ./INCLUDE /I ./INCLUDE/WIN32/ARES /Fosrc/ /nologo
/D FD_SETSIZE=16384 /D NOSPOOF=1 /c /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONST
DC_NO_DEPRECATE /D _USE_32BIT_TIME_T src/socket.c
socket.c
        cl /MD /Zi /J /I ./INCLUDE /I ./INCLUDE/WIN32/ARES /Fosrc/ /nologo
/D FD_SETSIZE=16384 /D NOSPOOF=1 /c /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONST
DC_NO_DEPRECATE /D _USE_32BIT_TIME_T src/s_conf.c
s_conf.c
src/s_conf.c(1525) : error C2146: syntax error : missing ')' before identifier '
mode'
src/s_conf.c(1525) : error C2081: 'mode_t' : name in formal parameter list illeg
al
src/s_conf.c(1525) : error C2061: syntax error : identifier 'mode'
src/s_conf.c(1525) : error C2059: syntax error : ';'
src/s_conf.c(1525) : error C2059: syntax error : ','
src/s_conf.c(1525) : error C2059: syntax error : ')'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
VC\BIN\cl.EXE"' : return code '0x2'
Stop.

C:\Users\therock247uk\Desktop\Unr3.2-20100708\Unreal3.2>

ohnobinki

2010-07-09 16:27

Apparently, mode_t doesn't exist on windows. I'll fix that today hopefully.

ohnobinki

2010-07-09 17:54

I blindly made a commit which will hopefully fix this compilation problem. Please test.

commit msg:
- Attempt to make up for Windows not having mode_t and not complying to POSIX.

therock247uk

2010-07-09 17:59

generate me a tar of it and ill see if it will go

ohnobinki

2010-07-09 19:47

reported as compilable by therock247uk.

- Fix references in src/win32 to aMotd to now be to aMotdFile.
- Fix references to motd and friends in src/win32.

Thanks :-)

1631

installing

feature

always

2004-03-08 02:32

2010-07-02 10:28

fez

normal

acknowledged

none

x86

Linux

2.4.x

3.2-RC2

open

call me crazy, but.... (src/modules/Makefile.in)

alright this is a little suggestion... kind of a philosophical one really. I'm anxious to hear your replies.

When I download a new version of Unreal, the first thing I do is modify src/modules/Makefile.in, so that....

instead of compiling every .c file into this giant l_commands wrapper at once (which takes like an hour on my p/166), and then compiling each and every .c into it's own .so,
I instead remove -DDYNAMIC_LINKING, and compile each of the .c files into a .o object, then just link them together to form commands.so

as a result, compilation time is improved CONSIDERABLY, and, on systems which have the nasty sig11 problem (like mine) or have some other issue, a break in compiling in the middle of commands.so doesn't mean i have to start the whole thing over from scratch!.....

On the downside... a power-user wouldn't be able to select the very specific commands they wanted to load by loading the individual .so's instead of commands.so, but...
a power-user who wanted to do that could probably figure out to do a make custommodule on them, and really I don't think anyone cares whether every single .c has a .so....

so to summarize, I suggest compiling to .o instead of .so to save time and accelerate potential changes to individual changes to modules... (e.g., now if i make a little modification to, say, m_whois.c, i don't have to recompile the WHOLE commands.so... just that one object, then re-link).

Even if this idea is turned down I still think it might be nice to have an alternate Makefile... or perhaps make this a ./Config option or something......

Thoughts?

-- fez

Rocko

2004-03-08 08:20

Maybe, you should buy a new PC. P166? Looks like, your PC is 9 years old :P

codemastr

2004-03-08 12:34

Heh, don't make fun of a P166!

Anyway, what I think I'm going to do before 3.2-final is a ./Config question

"Do you want to generate commands.so? Or just the individual m_commandname.so?"

Or something like that. That way for those who still want both, they can have both, for those who want one, they can have one.

aquanight

2004-06-04 01:26

Heh, still open? ;)

Anyway, sorry to dig up an oldie, but...

Is it possible to have commands.so just turn around and reference the individual .so/dll modules, instead of compiling the .c's into .so/.dll and then into a single blob that is the current commands.so/dll? This would not only maintain compiling the m_* to .so/.dll (and providing the ability to leave some out), but also reduce compile time and disk space usage by not having multiple copies of the same code (one in commands.so/.dll and one in m_*.so/.dll). After all, the purpose of shared/dynamic-link libraries is to reduce disk space by having the code exist in one place that all executables share - hence *shared* libraries.

*edit: maybe not the _only_ purpse, but that's a pretty significant one if you ask me...*

edited on: 2004-06-04 01:27

syzop

2004-06-04 14:33

Actually in our case that's not the the purpose, nor is it significant.. In fact if you would link in the modules statically it even uses a bit less hd space and less memory (less headerstuff, less extra memory areas, etc) ;). Our modules are not like libraries in the sense that other programs use them, so what you said doesn't make much sense... Then again I think you already realized that ;).

The main advantages of modules for us are:
- Easy to have 3rd party coders code stuff and plug them in
- Possible to upgrade parts WITHOUT rebooting the ircd (could even fix security bugs in cmds without reboot!)
- You can rip out commands if you want (with that one you can save mem, although that's rarely the reason.. Instead, think of people hating certain commands like /addline ;p)
- You can make certain 'choices' at runtime / without recompiling, like in CVS which requires you to load one of the cloaking modules.

aquanight

2004-06-04 14:40

Yeah, but as I said, having two copies of the same code is just a waste of space. By having command.so just reference the individual .so's it could not only reduce space used by duplicate code, but also allow admins to remove commands without having to switch from loadmodule "commands.so" to loadmodule "m_*.so", which may not be good because said admin may have other m_* modules that he doesn't want loaded atm (buggy, memleaks, abuse, other reasons) or already has a loadmodule line for.
For example, I just rename m_addline.{so|dll} to m_addline.{so|dll}.disabled. Commands.{so|dll} loads during /rehash, and tries to load m_addline.{so|dll}. Fails, so it just moves on (and not load that command). The only time such a ".{so|dll} not found" error would be fatal in this case is if it's one of the required commands that Unreal checks for (and says it's RTFM thing).

edited on: 2004-06-04 14:41

codemastr

2004-06-04 15:06

But it isn't the same code. It is slightly different.

aquanight

2004-06-04 15:12

Different code? You mean the MOD_* stuff? Or something else I'm missing?

Even if there are slight differences, my guess is that 99.9% of the code is identical, which is for me usually enough to consider abstracting/modulizing/whateverizing it. Unless there is some significant functional difference in having commands.so just reference the individual modules (besides performance hits). I dunno...

Though I can see that symbol references can be a major headache. You most definitely cannot use implicit or delay-load (Win32?) linking if you do this... ;) . Which means more fun dlopen()/LoadLibrary() calls ;) .

syzop

2004-06-04 15:31

I don't really like the idea.. It's like black magic in the background plus it requires all kind of work/implementation crap (=bugs)... The current way works just fine IMO.

codemastr

2004-06-04 15:49

Yeah I agree, spending 20-30 hours coding/testing doesn't seem worth it to save a few hundred KB of disk space.

syzop

2005-02-03 19:40

[quote]Anyway, what I think I'm going to do before 3.2-final is a ./Config question "Do you want to generate commands.so? Or just the individual m_commandname.so?"[/quote]

I'm beginning to like this, unfortunately I'm not really into configure/autoconf & friends so I don't think I can do this... but since a lot of code is (being) modulized, the extra compile time (and diskspace I guess) it requires is getting annoying [I'm on a P450 btw :P].

Currently I'm just commenting around in src/modules/Makefile whenever I need to recompile a lot, but that's a great solution, and it would be much nicer if it was automated ;p

ohnobinki

2010-05-06 23:43

Can we just use automake? :-D

syzop

2010-07-02 10:28

We should still have a question which should decide what to compile
1) Only individual modules
2) Only commands.so, cloak.so
3) Both

Should default to both I think, and should receive much testing.

I'm setting this to 3.2.10, it's not that important.

2701

ircd

feature

always

2005-11-19 03:09

2010-07-02 10:24

Robby22

normal

acknowledged

1.1.1.1.2.1.2.1.2.2234.2.399

none

i586

Red Hat Linux

7.3

3.2.4

open

Excepting some servers from a deny version block (like services)

I was thinking if there was such an option but it seems there isn't...
The reason being that I set a deny version block like so:
deny version {
        mask *;
        version <2306;
        flags eZ;
};

..and now services can't link unless I remove it again, so maybe it would be handy to be able to specify a server which is to be excepted from the version check like for example the Services server, while still being able to block all (*) other real servers not matching the deny version block.

w00t

2005-11-20 21:31

What services are they? Most (sensible) services send UnProto *, meaning all versions - which should make them exempt. Might want to talk to your Services people about that one :P.

(Auspice is the only one I know that doesn't follow this, by the way.)

Robby22

2005-11-21 00:14

The services I use is Anope.

If they do send * too, then it could be because of the flags setting, that's why I thought that it would be a handy feature to be able to except services from/in a deny version block.

aquanight

2005-11-21 12:40

I think there's a misdocumentation somewhere, either that or a bug, because I remember looking at the VL code and it wants a 0 for the version flags to be exempt, rather than a *:

if (*vflags == '*' || !strcmp(flags, "0"
))
result = 0;
(vflags is the deny version::flags field, and flags is the flags passed in SERVER)

w00t

2005-11-21 19:16

Hm @ aquanight, don't know where I heard *, but apparantly it's wrong :).

Robby: What I'm saying is generally if the services are well designed, they don't use a specific protocol version anyway-- I'm pretty sure Anope doesn't even send a NETINFO, though I may be wrong.

Robby22

2005-11-21 22:38

@ aquanight: Yes but that will remove compile flags that I specified that are required to link wouldn't it? I just want something like an exception-option for the protocolversion/flags-check for a specified server, so that it can link while still being able to keep a block on * without eZ compile flags.

e.g. something like:

deny version {
        mask *;
        version <2306;
        flags eZ;
        except-server "Services.Blah.Net";
};

@ w00t:
I do see some netinfo code in unreal32.c:

void unreal_cmd_netinfo(int ac, char **av)
{
    send_cmd(NULL, "%s %ld %ld %d %s 0 0 0 :%s",
             send_token("NETINFO", "AO"), (long int) maxusercnt,
             (long int) time(NULL), atoi(av[2]), av[3], av[7]);
}

/* netinfo
* argv[0] = max global count
* argv[1] = time of end sync
* argv[2] = unreal protocol using (numeric)
* argv[3] = cloak-crc (> u2302)
* argv[4] = free(**)
* argv[5] = free(**)
* argv[6] = free(**)
* argv[7] = ircnet
*/
int anope_event_netinfo(char *source, int ac, char **av)
{
    unreal_cmd_netinfo(ac, av);
    return MOD_CONT;
}

and:

    .....
    m = createMessage("NETINFO", anope_event_netinfo); addCoreMessage(IRCD,m);
    if (UseTokens) {
     m = createMessage("AO", anope_event_netinfo); addCoreMessage(IRCD,m);
    }
    ....

aquanight

2005-11-21 23:12

I don't mean the flags in deny version. I mean for anope to properly "exclude itself" from the checking it must report its version flags as "0" not "*".

w00t

2005-11-22 21:47

Which it looks like it's doing

aquanight

2005-11-23 15:45

NETINFO has nothing to do with it. VL information is sent in the SERVER message.

w00t

2005-11-24 00:59

Am I missing something? UnProto version is sent in the NETINFO message, are we talking about banning older UnProto's? Or something different :P

aquanight

2005-11-24 02:28

I was referring to the version flags (that doesn't appear in NETINFO).

(Btw - VL checking is done at the SERVER message before the link is even accepted, so the info in NETINFO wouldn't matter toward that anyway :) .)

w00t

2005-11-25 02:41

mm, point taken. :p.

stskeeps

2007-04-27 04:26

Bump, still an issue?

Robby22

2010-04-16 14:08

Yes, still an issue. Can't forbid older servers from linking, else services can't link either...

syzop

2010-07-02 10:24

fine with me *acknowledge*, but I probably won't do it (other priorities).

1245

ircd

feature

always

2003-09-13 11:13

2010-07-02 10:09

syzop

normal

confirmed

none

open

[3.3] I/O engine / poll() support

I'd really like to see the poll() system call (or the new system calls introduced in linux 2.6) to be put to good use. Because, as far as I have understood this whole matter and the way it is pointed out in the documentation, the main problem is that only fd_sets are supported, and the maximum fd_set size supported and hard-compiled into the linux kernel by default is 1024. This limit of 1024 file descriptors is not being imposed on poll() system calls, or the newer calls introduced into kernel 2.6.
Furthermore - the newer system calls are way more performant than select() or poll() itself.
This would make it possible to accept way more connections than just 1024, and in these times this limit is really pretty low.

original report / text @ description is by thilo, not by Syzop [!]. I just changed the 'reporter' to get rid of annoying comments.

syzop

2003-09-13 18:48

[about fd limits]
Well, most of the time the limit is enforced bu ulimits... Type "ulimit -n" at a random (default) *NIX installation, that will usually say '1024' (Linux, FreeBSD, ..). However, it's true that at Linux you won't have to do another step (besides increasing the ulimit): the editting of the header files.

[about performance]
They say poll is more CPU friendly, I'm sure that's true in theory (I know how it works), I'm not so sure if it matters that much on an average server with X00 clients however..

[in short]
poll() support would be nice, I certainly agree.. an "IO engine" rewrite is on TODO, I assume support for poll will be added then, I'm not so sure if it will be added in the meantime :/.

thilo

2003-09-13 19:35

####
Well, most of the time the limit is enforced bu ulimits... Type "ulimit -n" at a random (default) *NIX installation, that will usually say '1024' (Linux, FreeBSD, ..).
####

This fact is known to me. On machines with root access I can modify this limit. Thus, ulimits are of no concern in this discussion.

####
However, it's true that at Linux you won't have to do another step (besides increasing the ulimit): the editting of the header files.
####

Quite on the contrary: as far as goes to my knowledge, you have to recompile the whole kernel with the new FD_SETSIZE value in order to get the changes into effect. That this cannot be a solution, should be clear in my opinion.

####
They say poll is more CPU friendly, I'm sure that's true in theory (I know how it works), I'm not so sure if it matters that much on an average server with X00 clients however..
####

Well, I really think it does. Before each select, you have to add new file descriptors to your set, whereas in poll you can use the old array. Building up the FD_SET once is not really resource intensive, but imagine if you have more than 1000 messages per seconds, and you have to build the new FD_SET up at least 400 times a second ... it will get noticable!

syzop

2003-09-13 20:19

Well your 2nd and 3rd point are both incorrect, but anyway I think it's clear that we both would like poll() support.

thilo

2003-09-13 23:38

you're right ;)
I'll shut up already .. :P

syzop

2004-06-29 10:55

=> 3.3*, so not within a year or so.

codemastr

2004-06-30 23:53

I've been trying to conceive how difficult it would be to write a new I/O engine for Unreal. After looking at the code and trying to see what would be necessary, I had a nice big headache. If we were to do it from scratch, with just 2 people working on it, it would probably take us a few years to complete and work out most of the bugs.

Instead, I think the best method would be to adapt the new I/O engine from Hybrid. It's nice, it's semi-module friendly, and it would mean a bit less work. We'd just have to adapt it for Unreal, and add our own little features (e.g., SSL support). I haven't looked at the Hybrid I/O system too much, but I can't imagine it being too difficult to implement in Unreal.

I'm thinking the I/O engine should be the major feature of 3.3. To users, it won't seem like much of a change, but on the inside, Unreal will be vastly different, and much cleaner.

Syzop, any comments on this?

syzop

2004-07-01 10:10

I totally agree.
Just as you say.. I'm sure too it would take ages to code, and if finished it would contain tons of bugs (=most worrying ;p)... And these are NOT easy to trace bugs :p.

syzop

2007-05-08 08:46

Anyone interested in this, should also check http://dev.unrealircd.com/wiki/io_engine [^]
In short it comes down to porting the hybrid I/O to Unreal.

Darkelf did some early work on this, which was committed to 3.3*, but nothing substantial. So, there's still a lot of work left (pretty much all work).

Of course, this job is huge and even though it's copying existing code (and porting it), it requires extensive thought and knowledge of I/O subsystems (theirs and ours).

I certainly hope someone will come forward to do this ;)

syzop

2010-06-21 18:52

I'm willing to rethink about this for another release (I mean seriously reconsider it), but it's very very dangerous to change any part of the I/O engine, so it requires EXTREME care.
One subtle error, or incorrect ordering of things and you get very weird bugs which might only appear during stress and certain specific types of stress or sequence of things.

It will not be done for 3.2.9.

Normally it should be for 3.3*, but I'm willing to reconsider it for 3.2.10 or whatever it will be. We'll see. We're talking about 2011+ then anyway.

And yes you can post another thousand comments here but I will not read them, the point is already clear :P

EDIT: hah, I only saw just now that the view status was 'private', probably for the same reason as mentioned above (comments), it's now 'public' again.

3720

ircd

major

always

2008-08-17 18:57

2010-07-02 10:03

fez

syzop

normal

assigned

none

x86

Linux Mandrake

2.6.24.2-1fez

3.2.7

reopened

ULines and Server can set channel mode +z when insecure users are present causing an "invalid state" of security

M_MODE does not do any checking to see if insecure users are on a channel when setting mode +z, IF the setter of the mode is ULined or a server.

This means that, for example, I could set MLOCK +z on a channel (via services), then a new (insecure) user could join the empty channel, and services would set mode +z, and the user would remain on the channel.

Since M_SJOIN enforces +z rules, in the case of a netsplit/netrejoin, so, too, should m_mode enforce +z rules even if the MODE command comes from services/uline/server.

Here is the fix:
I forget what is the diff command to create the appropriately readable patch.

**********
src/modules/m_mode.c line 829 --OLD (from 3.2.7 release)--

      case MODE_ONLYSECURE:
          notsecure = 0;
          if (what == MODE_ADD && modetype == MODE_ONLYSECURE && !(IsServer(cptr) || IsULine(cptr)))
        {
          for (member = chptr->members; member; member = member->next)
          {
            if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))
            {
            sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),
                   me.name, cptr->name, 'z',
                   "all members must be connected via SSL");
            notsecure = 1;
            break;
            }
          }
          member = NULL;
          /* first break nailed the for loop, this one nails switch() */
          if (notsecure == 1) break;
        }
        goto setthephuckingmode;

**********
src/modules/m_mode.c line 829 --FIXED--

      case MODE_ONLYSECURE:
          notsecure = 0;
        // modified by fez, so if servers set onlysecure mode, it honors it and removes insecure users
          if (what == MODE_ADD && modetype == MODE_ONLYSECURE)
        {
            if (IsServer(cptr) || IsULine(cptr))
                    {
                kick_insecure_users(chptr);
            }
            else
            {
                for (member = chptr->members; member; member = member->next)
&nbs