/oper idea

[Syzop]

I don't like this feature myself either...
It is also EXACTLY where remote includes are ment for.
Remote includes support is build-in on both windows versions (ssl&nonssl), and on *NIX to install it you just execute a few commands (download A, extract, download B, extract, run ./curlinstall with correct paths, done.. [and then ./Config]).
Obviously if there are bugs in this, they should be reported on http://bugs.unrealircd.org/, but nobody has done that.

[w00t]

May I just point out katsklaw, that as you just pointed out, anything from global op upwards can affect the whole network, meaning that restricting their login to a particular server is rather silly.

aquanight, a valid issue as to raising success... One that I hadn't considered. I'll think on that for the next few hours.

Syzop, I compile from source. I don't use precompiled binaries
As for nix, well the libraries don't seem to like my PC, and ...caused a few problems. (namely, I had to wipe it clean and reinstall slacky to get the thing working without erroring constantly.)

[katsklaw]

May I just point out katsklaw, that as you just pointed out, anything from global op upwards can affect the whole network, meaning that restricting their login to a particular server is rather silly.

/rehash
/restart
/locops

yes I know that the ability is there to do this remotely, however not everyone uses them remote includes or allows for remote rehashes.

Also picture a net that uses this feature and/or remote includes. Joeblow Oper gets pissed off and starts causing havoc. He splits the net with a few well placed /squit's .. His admin has had enough and removes his oper block and rehashs.

Old way:
1> remove O:Line/operblock and rehash. Story ends.

your way:
1> remote includes would have to be progated to all split servers
2> all references to Joe's operblock would have to be removed from cache and/or each ircd.conf file and the servers would need to be rehashed individually since they are split.

While your busy trying to remove his access all over a split net he's bouncing from server to server having fun.

Get the picture?

Some things are better off left unchanged or just changed slightly to improve upon .. a wheel has vastly inproved over the thousands of years in existance but it's always been round and attached in the center.

[Theos]

The way i understand w00t's suggestion puts your scenario out the window katsklaw: the olines wouldn't be copied across to the conf file - they wouldn't be copied anywhere.
When you do a '/whois nick nick' you are asking Server-B to relay the information to you without looking up any info on Server-A. With an '/oper blah 12345 Server-B' you would be asking Server-B if that oline exists from Server-A.

- A to B: Joe Bloggs wants to oper, do you have an oline for him?
- B to A: Yes i do, give him xyz flags and amend personal struct with privileges
- A to Joe: +xyz umodes

- A to B: Joe Bloggs wants to oper, do you have an oline for him?
- B to A: No i don't, tell him to sod off!
- A to Joe: Sorry, not today, i have a headache.

If the network was then to split, you wouldn't be able to oper up in this manner as there is no Server-B to ask. If the network was still linked and the oline removed from Server-B, the /oper would fail as Server-B would say no olines exist.

Being a globalop there's not much difference in this, except it would allow you to connect to the DNS pool and not have to worry about connecting direct to the server with your oline on.

[katsklaw]

Ok, check this out.

With your /whois example. If you whois a user from a server that is split then you get a no such server error back. If you use the O:Line in the same fashion, then you can only oper on servers that are connected. So whats the point? .. just stay on your assigned server.

So in order to oper on all servers regardless of their connection, O:Lines would have to be cached and updated on a regular interval. If the net splits then Joe can oper on all sides of the split even if you remove his O:Line from Server A .. he can still wreak havoc on any other split servers.

Hence my scenario.

It's not so tough for opers to be assigned to servers, it's worked well for years. There is no great advantage to this concept.

[w00t]

No, there would be no caching the way I imagined it working. Instead, it would work as Theos suggested. However, as has been pointed out, it is (probably) impossible to return a success, and therefore this is really a moot point.

All this would mean that it would REQUEST to see if the user could oper, meaning it wouldnt work during a netsplit. I don't know how to say this, but you have the wrong idea of how I envisaged this

[katsklaw]

well I'm trying lol

I can see it working like /whois does .. the info could be returned the same way. however, as I expressed before .. I don't see the point. Having an oper assigned to the same server is not a bad idea. It works that way just fine and changing it to work your way would, IMO, cost more in grief that the ability for an oper to use any server he/she wishes is worth.

[w00t]

You're doing great

As I said, my problem comes from us only having a DNS pool, meaning I don't get to choose where I end up. Then, if we have a netsplit, i may be the only active oper. We don't use autoconnect (in case something goes screwy-- i hate the snotices and having to jupe a server) so it would be good if i could ask server1 for oper, so i can reconnect server3 to the net.

[katsklaw]

u can always /server some.ip.address Infact, it's a good idea for all opers to connect to the IP and not the host simply if DNS don't work .. they can still maintain their servers.

[w00t]

Yes, but a few bad thingies here:

First, i am forced (not my decision) to use cgiirc.
Second, I don't know the IPs, not can I (really) be bothered to commit them to memory...

Anyhow, I just thought this would be a useful feature, so back on topic