If I migrate rancher to another server and github authentication is already turned on, then on the new server, if I try to log in, I’ll get redirected to the old server (that I’m guessing this has more to do with github than with rancher, but I’m not 100% sure). The point is, how can I disable github authentication through the command line?
Is there really no answer to this? I’d have really preferred it if I didn’t have to disable github authentication in production and to have to implement iptables rules or something to that effect.
Rancher points at one GitHub app, and one app points at one return URL. So “no”, but a much cleaner way of migrating would be to have a DNS name for the installation. Then to “migrate” you change where that points to and the config of auth, host registrations, etc can stay all otherwise the same.
Right, but you have to accept that sometimes this simply isn’t a solution and you have to move it to a different domain/ip.
It seems weird to say the least that you wouldn’t be able to do that as a sysadmin with full access to the docker. This isn’t a “feature”. This is basic configuration, really.
You still need to change the GitHub app to point at the new name. They’re the ones that control the redirect. If you don’t care about both servers working at the same time, that’s all you really need to do.
If you want both working simultaneously, then one of them has to change to a different app. 1.x UI does not (and will not) support changing GitHub config without turning auth off temporarily, but you can edit the githubConfig in the API.
(Or, everything is in MySQL, so you can exec in to the container [if using the internal DB] and connect to it and change the setting in the settings table.)
The easiest way would be to make a new app and change the old server to use it, since you can get into that one. Then change the old so to point to the new name.
I understand.
But if you happen to somehow lose access to the github account, then I guess that’s that, right? You won’t have any access to your rancher server, even if it’s running on your server and you control everything there.
There’s something in that logic which doesn’t really sound correct, but I might be wrong.
I’m not sure what your point is; It’s not going to be something we recommend right of the bat but as I said you can always exec into the container/connect to the DB and twiddle settings if you really need to turn auth off or reconfigure it.
Well, that’s exactly what I was asking, actually. Where would I be able to find the authentication settings in the databse, if there’s no particular command that does that?
My point is that the sysadmins are deprived of control over their own servers. But, as I was saying, if there is a more or less straightforward way to do what while guaranteeing nothing is broken (of course, that’s the sysadmin job also), then there’s no issue whatsoever.