Globals

[Moogey]

Hello there,

When an ircop is defined as global, are you supposed to be able to login in with that oper on other servers without it if they're linked?

I have two servers linked but only the opers defined in the linked server's config can login.

If it's not supossed to do this, I suggest it. I think it would be a great idea just in case a server goes down. Just for globals.

~Moogey

[Darvocet]

Hello there,

When an ircop is defined as global, are you supposed to be able to login in with that oper on other servers without it if they're linked?

I have two servers linked but only the opers defined in the linked server's config can login.

If it's not supossed to do this, I suggest it. I think it would be a great idea just in case a server goes down. Just for globals.

~Moogey

In order for any oper of any level to oper up, their 'oper block' must be listed in the server's config files on which the user is connected. For example, if you have 2 servers one named 1.example.com and one 2.example.com. If OperNick is an oper on 1.example.com he will not be able to oper on 2.example.com unless you write a link block there for him too.

I hope that is clear. Each server must have a list of opers which are allowed to oper on that server.

[Moogey]

Ah, I understand now. Thank you.

I suggest this in that case for future releases.

[Jason]

In case the link goes down.... Right. What if you WANTED it to go down. What if you dont want those people to be opers anymore? Bad idea, isnt it?

[Moogey]

Hmm, well aren't you a big bundle of joy. Thank you for your kind reply.


I don't get what you're saying, but this would be useful to me. Anyway, if you don't want somebody being an op anymore, you couldn't change that anyway if the block is on another server, so there's nothing different.

You need a serious attitude adjustment.

[Matridom]

moggey, remote includes was done for just such a reason

make the oper block web accessible (password protected webfolder with encrypted passwords) and use the remote include to fetch the oper block.

That way, every server has the same oper blocks and you can easily modify one user and have it affect everyone.

[Moogey]

Matridom: Thanks for the tip

Jason: Ah, I get what you're saying now. The oper blocks would come remotely so long as the servers are connected. Once the servers unlink, they wouldn't be able to oper anymore since it can't get the blocks.

[aquanight]

That could work in theory, with one slight problem:

Unreal presently doesn't have any [reliable] way for a standard (eg, client or hub) server to grant oper privileges or the like to a user on another server. Such a capability is limited only to either the local server that user is on (in response to a successful /oper) or to U:Lined servers (which are basically your services, stats, etc).

Since U:Lined servers can tinker with remote user's oper privileges (including both granting and removing them), it's possible to code a service daemon to connect as a U:Lined server and implement an authentication mechanism to grant oper privileges to a user independant of what server that user is on. (You can also use the module feature in some service packages.)

I should point out, there are a few downsides to a centralized oper login type system:
- You are relying on an external source for authentication. If that source goes down, then in the case of remote includes , no configuration updates can be made until the remote include server returns. In the service approach or with "shared olines" through some server-to-server protocol addition, the distributed opers would be unable to oper if services or whatever the host server is goes down.
- Server admins should generally have control over who can and cannot oper on their server (and some server admins will strongly agree with this). A distributed oper system would take away that control.

Advantages, of course, exist: in either case, being able to login as an oper is still possible as long as the oper can access one server, and the server hosting the login is still reachable from IRC. In the case of services-hosted olines, the NOOP mode in servers can be bypassed (SVSO command bypasses SVSNOOP ;) ) if a takeover has left all your servers NOOPed (although, in at least anope 1.7.10 you could just open OperServ to nonopers and have your admin/whatever un-NOOP everything thus avoiding a massrestart which can be a pain in the ass if an admin or two is AFK...).

However, I think the problems I mentioned above, in addition to the presence of an already-working solution (remote includes, and SVSO) is probably the reason why unreal doesn't have support for this natively.

[Darvocet]

I should point out, there are a few downsides to a centralized oper login type system:

Assuming these servers are running linux I would recommend a small bash script that uses SCP to send all your config files to the other servers. This is what my network uses to update it's 8 servers. All updates are done on 1 server, then they are sent over secure shell (SCP) to all the other servers. This way every globalop can oper on any server, and keeps the other things the same network wide.

[Moogey]

Thanks for the advice you guys, I will look into it.

As of right now, my server hasn't been started but I'm in the process of starting a network..

I am 16 and need some more cash first and people willing to provide links (I can see it up in a month or two, realistically)

[aquanight]

I should point out, there are a few downsides to a centralized oper login type system:

Assuming these servers are running linux I would recommend a small bash script that uses SCP to send all your config files to the other servers. This is what my network uses to update it's 8 servers. All updates are done on 1 server, then they are sent over secure shell (SCP) to all the other servers. This way every globalop can oper on any server, and keeps the other things the same network wide.

While this does solve the external source problem, it doesn't solve the admin control issue ;) . However, using a shared config for such network-wide things like cloak keys, cloak prefix, network name, services/stats servers, ulined server(s), and possibly other things can help relieve some things like trying to update a million servers when your cloak keys are compromised and you need to change them ASAP... I'm sure everyone has had their Murphy's Law experiences. (Specific "law" in question: When a network config update needs to be done yesterday, at least one of your server admins will be AFK. :P (ok, I just made it up, so what))

[Darvocet]

Specific "law" in question: When a network config update needs to be done yesterday, at least one of your server admins will be AFK. (ok, I just made it up, so what))

Yes that is true. That is the thought behind my SCP script. Instead of having to login to 8 servers to update I can just login to 1 server and update them all. If I needed to change the cloak keys, or remove an oper, I can update the confs in 1 place, run "./update" and each server on my network gets the new copy of the confs, and a php scripted bot rehashes each server making the changes instant. Am I missing something else you were talking about?

[mexx3k]

a php scripted bot rehashes each server making the changes instant.

why don't you write an alias for your mirc / xchat / ...?

Code: Select all

alias rehash {
rehash server1.net
rehash server2.net
rehash server3.net
}

or a small bashscript which connects to the remote server over ssh and sends the "./unreal rehash"-command?

the first solution works very well, i want to test the second in the next days ...

[aquanight]

Because not everyone uses a scriptable client?

There is a way to possibly use services to mass-rehash the network. I'll see about making an anope module to do it some day...

[Darvocet]

Because not everyone uses a scriptable client?

You are correct sir! Also its easier for the linux box to rehash when it does the update rather than to rely on some user on IRC to do it with a script. I am not 'ALWAYS' online, and if I want to make sure the machine was rehashed it just makes way more sense to do it through linux at the same time as the update script. Relying on scripting too much could lead to problems later on.