DNS discussion
-
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
-
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
Exactly this
Why would it be manual? What situation is causing there to be any amount of work?
I love my playbook for this. I have reservations but they don't auto update DNS. The dict has the host info (address, record type, mac, etc) and generates the reservation and adds the A and PTR at the same time. Any changes are done in Git and it's all automatic.
-
In all our schools we have a Solus3 deployment server that uses reverse lookups when you're doing initial client setups in it. Solus3 updates SIMS and FMS which are the MIS and finance systems that run the school.
-
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
-
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
-
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
Don't...
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
It's "easy". And I mean that literally. Like it isn't complex at all. It takes a lot of manual effort, but just busy work, nothing hard.
-
@coliver said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
Don't...
It's not my choice. We inherited this nightmare. We will eventually switch to DHCP but I don't dictate when that happens
-
@wirestyle22 said in DNS discussion:
@coliver said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
Don't...
It's not my choice. We inherited this nightmare. We will eventually switch to DHCP but I don't dictate when that happens
Well you could
You just say "line in the sand, stop making me waste time to play around when there is a fix and you aren't letting me fix it." You always have that choice, of course you might have to walk, but would they really axe you because you pushed them to save money, fix things earlier and reduce workload that was just busy work? -
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
-
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@coliver said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@Dashrender said in DNS discussion:
@scottalanmiller said in DNS discussion:
@JaredBusch said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
@Dashrender said in DNS discussion:
@stacksofplates said in DNS discussion:
For me it's mostly convenience. Another use other than what I mentioned before is I can quickly find what machine a person SSH'd in from.
But I know FreeIPA replicas need it because I just installed one this morning and had to add the PTR.
OK these are useful tools for IT, but they aren't requirements. The system won't suddenly stop replicating, or authenticating, etc because you don't have reverse DNS setup.
It's kinda obvious that Wire has a mess in his static environment. I'm thinking that he should just kill the reverse entries to prevent the problem he experienced in trouble shooting this.
He also needs to kill WINS, but that's another matter.
It literally won't install the replicate without it so it is a requirement.
So let's reverse the question. If nothing relies on it, how can the reverse be screwing anything up?
Well, in this case - it led someone to a wrong conclusion to the root of a problem. Now this isn't the fault of reverse DNS.
But having to maintain a manual reverse DNS table can be a fair amount of work, and if it offers no value, why do it?
And I think you answered your own question here. It may have led them to the wrong conclusion based on bad information, but one that is properly set up is useful or else they wouldn't even have been looking there.
Right, if you are going to have a static network, then this is simply one more thing that you have to deal with as I said earlier. Not doing it is going to cause problems sooner or later.
Right.... layers of mistakes where one mistake is leading to another based on it. If PTR records take any effort, don't ignore the real problem by not updating PTR, instead, fix the actual problem.
Of course - but Wire doesn't control their decision or timing to move to DHCP.
Doesn't change the fact that it is a mistake in the design and planning. The question was not put as "should we work around someone intentionally blocking a fix."
How do you operate in a completely static environment is more what I'm wondering. First time I've ever seen this tbh.
Don't...
It's not my choice. We inherited this nightmare. We will eventually switch to DHCP but I don't dictate when that happens
Well you could
You just say "line in the sand, stop making me waste time to play around when there is a fix and you aren't letting me fix it." You always have that choice, of course you might have to walk, but would they really axe you because you pushed them to save money, fix things earlier and reduce workload that was just busy work?That doesn't benefit me. I can offer advice and explaining the reasoning behind a decision but at the end of the day it's their choice. If they decide to not follow my advice then I just accept it and move on. Once I get to where I need to be RHCE wise I'll hopefully just leave for a better job anyway.
-
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
-
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
You still only have one person to convince, the city.
-
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
You still only have one person to convince, the city.
It's an improvement
You always have the customer to convince
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
You still only have one person to convince, the city.
It's an improvement
You always have the customer to convince
No, I mean RIGHT NOW. You , today, have only the city to convince. Those MSPs above you are not decision makers.
-
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
You still only have one person to convince, the city.
It's an improvement
You always have the customer to convince
No, I mean RIGHT NOW. You , today, have only the city to convince. Those MSPs above you are not decision makers.
I don't interface directly with city management. The company who holds the contracts do so if they decide to not do something it would never be brought up to the city in the first place
-
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
@wirestyle22 said in DNS discussion:
@scottalanmiller said in DNS discussion:
Who DOES determine that you will not fix things properly today? Who is making that decision right now and what was their reasoning?
I've realized that if I wanted everything to be done the way I think they should be done I need to create my own MSP, which I'm not ready to do yet.
No, MSPs make no decisions. Customers make those decisions. If you want to do things the way that you want them done, you have to stop working at an MSP and start being a business owner. There is no other position that gets to do that.
In this case I'm a subcontractor so I have 3 levels of people to convince:
- My boss
- The company that holds the actual contract with the city.
- The city themselves
If I were an MSP I'd eliminate two of those
You still only have one person to convince, the city.
It's an improvement
You always have the customer to convince
No, I mean RIGHT NOW. You , today, have only the city to convince. Those MSPs above you are not decision makers.
I don't interface directly with city management. The company who holds the contracts do so if they decide to not do something it would never be brought up to the city in the first place
You are the sole on site IT advisor, and they don't talk to you? They literally have on interface between the CIO and the senior IT person?
