I am currently in the process of updating and modernizing my company's internal network, and as part of this we are replacing two old Active Directory servers (serving DNS as part of their Domain Controllers role) with two new ones. This part of the upgrade has been completed: the new DCs are online, roles have been shifted over, DNS is working. For now, the old DCs are still on the network as DCs, though the plan in the medium term is for them to be demoted and removed when the time is right.
This has revealed an issue with the oVirt servers we have, though: Their DNS entries are still pointing at the (static) IP addresses of the old DCs. This became obvious as an issue when after some physical relocation of the DCs, we were unable to log onto the (AD-auth-using) oVirt console until the older DCs were also powered back on. We cannot move the IP addresses around, the oVirt servers need to be changed to use the new DCs as their DNS servers.
I have located files at /etc/resolv.conf , /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt and /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt , all of which contain lines with the IPs of the old DCs in, but it is not obvious which of these if any are being automatically generated. I have done reading around the subject and it is suggested that the latter of the three is the main configuration file but this is also the only one that's been modified in the last 2 years - specifically at the time when the servers were last powered up following their move.
Which, if any, of these three files should I be editing? If none, where should I be?
You have two options:
change the DNS globally for the Logical Network marked as Default Route (typically the Management network). Go to Compute → Data Center → YourDC → Logical Networks → YourDefaultRouteNetwork → Edit and look for the DNS section. This is the preferred method.
change the DNS per host. Go to Compute → Hosts → YourHost → Network Interfaces → Setup Host Networks → YourDefaultRouteNetwork and click on the pencil ✎ symbol. From there you can set the DNS servers.
N.B.: do not attempt to change the DNS configuration directly from the host files, since this will end up with the oVirt configuration in the PostgreSQL going out of sync with the one in the hosts.
Related
In the past, the domain was hired and used on a physical server (which still exists today)
And now I need this domain to stop directing the old physical server and start redirecting to the new one (which will also be physical)
Old Server : Linux Apache
New Server : Windows (IIS?, Apache?, WAMP? is still being decided)
Can someone give me a tip? I'm in the dark here
The first thing you should do is find the nameserver addresses available on your new hosting account.
The quickest way to find your new hosting account's nameservers is to look at the information in the email your hosting service sent you the first time you purchased hosting, or from the documentation provided by your hosting service's website. If you're still confused about where to get one, contact your hosting provider and ask them for a “DNS server” or “name server” for your domain.
Nameservers are usually in the form of ns1.companyname.com, ns2.companyname.com, etc., where companyname.com is usually the name/brand of your hosting service.
Your hosting service will generally provide 2 or more nameservers that you can use. Write down all the nameservers. It would be even better if you save the email/web page that contains the nameserver info so that later you can copy and paste it directly. Later in the next step, you must enter this nameserver information into the control panel where you purchased the domain (registrar), exactly as stated.
After you get the nameserver information, go to the domain control panel at your registrar. Don't forget, this means you're logging into the system where you bought the domain and going to where the domain management section is.
Once you find the appropriate page to change your nameservers, you will usually see a form that will allow you to enter Nameserver #1 (or “Primary Name Server”), Nameserver #2 (or “Secondary Name Server”), and maybe a few others (such as the 3rd and 4th nameservers). The terms may not always be the same, but the basic meaning will still be your first nameserver, 2nd and so on.
Fill in your nameservers, usually starting with ns1, into the Nameserver #1 field. After that type your 2nd name server, usually the name starts with ns2, to Nameserver #2, and so on. A domain name has at least 2 name servers associated with it. Some web hosting services provide more than 2, some only 2.
After the nameservers are installed with details, done. You only need to wait a moment until your website can be accessed using your domain name. Usually, it only takes a few hours for the machine to work properly.
You need to log into your Registrar account and update your DNS to point the domain to the public IP address of the new server.
This is normally a fairly easy and quick change. As an example, you can check out how to make DNS updates on GoDaddy here.
Depending on which new server you chose and the server provider, there may be additional steps involved in order for the new server to receive external traffic. Additional steps may include, but not limited to, updating a firewall and configuring the server settings.
I am working on an embedded software product that runs on an Ubuntu edge computer with multiple network ports.
The software allows the user to change the IP address of the ports via a locally hosted web interface.
In the scenario that a customer changed an IP on one of our devices, but then forgets their setting I am looking for an easy strategy to walk them through detecting the IP.
Ideally this tool would be usable by non-sophisticated customers (we don’t want to walk them through using Wireshark or command line tools).
Is there a service we can setup on our machine that will broadcast its identity across subnets using another protocol like UDP or EtherNet/IP? Then a simple tool the client could install on their computer to ‘scan’ for our devices?
The edge computers also have USB ports if it is easier to broadcast an identify there.
Changing a local IP address to something invalid (=not compatible with its local subnet) generally disables all L3 communication. Limited broadcasts (to 255.255.255.255) still work, but answering to them by unicast most likely won't. The same goes for multicasting - but you could use that for discovery both ways.
Also, the common link-level discovery protocols (like LLDP or CDP) still work since they don't rely on IP.
However, all that is limited to the connected L2 segment at most. Discovery across subnets isn't possible without some kind of infrastructure (discovery sensors, central server, multicast routing, ...). A reasonable way would be dynamic DNS but then again, that requires IP to work.
I think you'd need to take a step back and reevaluate your design. One way would be to verify a user's reconfiguration before it becomes permanent. For instance, you could have a user change the IP setup and then forward the session to the new IP address. If the session isn't continued within five minutes or so on the new address, it reverses to the previous config.
Additionally, some kind of out-of-band management could be useful.
We decided to move dev machines (PC's) into the cloud in the form of Amazon Workspaces. In simple terms, a provisioned workspace is very similar to a PC accessed via RDP. However, the scaffolding for the service assigns a 'unqiue' computer name to each workspace. We wanted to set a specific computer name and therefore we connected to the workspace and used the standard Windows technique of going into Properties on "This PC". Windows prompted to restart, which we did. Thereafter the workspace was unreachable from the Windows WorkSpaces client stating the status was Unhealthy. The WorkSpaces Management status was initially REBOOTING then PENDING. Finally it showed UNHEALTHY.
It is not unusual to want to change the computer name, particularly if modelling a current physical config into the cloud. However it looks like this derails / confuses the workspaces scaffolding.
Question: How to make the workspace reachable again, especially if much time investment has been made configuring it?
I shall provide the answer that solved the issue for me, which I leave for others hitting this issue and in the hope that it helps.
I found the basis of this answer in the Amazon Workspaces forum from the same question asked by JoeA in 2016. It took me a while to find - see the original post here. which I shall paraphrase following in case this precious link breaks in the future.
Amazon's answer was:
Changing the computer name on your WorkSpace will cause the PCoIP application to fail, so you won't be able to connect to it using the Amazon client.
To connect to the workspace, you can edit the security group associated with the workspace's ENI and allow TCP traffic on port 3389 so you can RDP into it.
Once you are connected to the WorkSpace, rename it back to the original name and reboot it and you should be able to connect again.
JoeA responded:
Thank you very much for your reply, there is hope! I'm a newbie with AWS and Workspaces. Can you provide more details, or point me to a document, on how to access the Workspace using RDP? I searched the forum, but no luck.
Specifically, I don't know how to "edit the security group associated with the workspace's ENI and allow TCP traffic on port 3389 so you can RDP into it" as you state. I did find under the "Directories" setting that my "Security Group" is set to "None selected". (FYI, I have only this one Workspace.) "Access to Internet" is set to "Enable", if that is a factor. Thanks.
JoeA then followed up with the solution which was, in his words:
The changes to open the port are under the EC2 console, not the Workspaces console where I was originally looking. I found the Security Group for Workspaces, and changed Inbound traffic to allow RDP (port 3389). Then also on the EC2 console, I found Network Interfaces that shows the public IP. (I first tried to RDP using the IP shown in Workspaces console properties ("WorkSpace IP"), but that must be a local IP inside that network.) RDP'ing to the public IP, I connected and put back the original machine name, restarted, and now I can connect again using the Workspaces client again.
Thanks JoeA for that good work.
I have a domain controller set up in an Azure VM, and a couple of other servers also set up as VMs. When I set up the server VMs, I configured DNS and WINS to point to the IP address of the DC and joined them to the domain. However, these settings don't survive a shutdown (where the VM is deallocated). When the VM is started back up, DNS and WINS are empty, and domain authentication does not work.
I read that I should provision new VMs via PowerShell commandlets, specifically setting up domain joining. I tried that, and maybe I got something wrong, but it didn't work -- the newly provisioned VM was not joined to the domain, and did not have DNS/WINS set to point to the domain controller.
In any event, my question is: is there any way to re-configure an existing VM to retain network settings through a shutdown or is my only option to figure out how to provision a brand new VM to be married to the domain controller, and then to start from scratch?
Thanks!
You shall never use static configuration on your Azure VM! Neither for IP Addresses, nor for DNS Settings. What I recommend to use is a long story you can read here. It is tested, validated and proven to be effective. A short extract follows:
You should setup at least two sub-nets. Leave one solely for the DNS (and AD/DC if it happens to be the same server). Put all rest of the machines in the other Sub-Net. Thus, you will have 100% predictable IP Address of the DNS Server machine. Having that in mind, configure the DNS for the virtual network via the portal or via PowerShell. But explicitly configure DNS Server for that virtual network. Set IP address for the DNS - the one that you know it will have!
Please do never forget - never manually change network configuration settings for an Azure VM! Doing so is a path to failure.
The above method will help you resolve DNS issue. Now, for the WINS. I don't think you can configure WINS via Virtual Network settings. So, if your VM really loses WINS config, you can create a small powershell script that runs locally on each VM to configure WINS settings upon boot. You can either make this script more generic by looking up the DHCP assigned DNS server and use the same IP Address for WINS, or just put it static, because you know what the IP Address of DNS server will be.
Anton presents a clever and perfectly workable solution, but I wanted to understand what exactly I was doing wrong, because Microsoft guidance suggests that it should be perfectly possible to set up and maintain an Active Directory domain the in the Azure cloud without putting the DC into its own subnet.
After a lot of trial and error (mostly error), I finally figure it out. This is not well documented, so hopefully this will help someone:
In Windows Azure, cloud service is another term for application, or a set of components that scale together. A cloud service is assigned a single DNS name and a single external IP address. In the context of virtual machines, you typically have a 1:1 correspondence between a cloud service and a virtual machine. You only add additional virtual machines to an existing cloud service when you want Azure to automatically load balance and distribute requests among the VMs inside that cloud service, treating them as if they were one.
This brings me to my mistake. Not fully understanding the above, I was attempting to add a new worker virtual machine to the cloud service in which I set up my Domain Controller. That is not a supported configuration. Once I understood that, and properly configured a new VM into its own cloud service, associated with the domain controller as DNS server, everything worked perfectly.
For my development process I need to access a webserver which is behind a VPN and has no DNS entry.
What I was doing on 4.x was to edit /etc/hosts on the iPhone, and add it to the hosts file.
Now I'm on 5.0 beta, and don't want to jailbreak for now just for this purpose.
Is there a way I can add a line to /etc/hosts, just for development purposes (the final, distribution application does not need this hack), without jailbreaking? Can I use other means (declare a fake DNS entry by some unknown means at application launch, for example)?
EDIT: If you're willing to purchase a small license, I recommend using Charles Proxy, a web debugging proxy tool. It will also resolve domains from your local /etc/hosts, and it gives a lot of bonus features (i.e. inspect requests/responses and throttle network speeds). I only stumbled upon this tool from a WWDC video and I'm not affiliated with the product at all. I recommend reading Chris Ching's tutorial for iPhone and Charles Proxy to get you started.
To add to Ramon's answer, a way around it is to setup your local computer as a DNS server and have your iPhone point to your computer as a DNS server. This would also work for Android devices as well
The instructions are for Mac OSX via Homebrew:
brew install dnsmasq
dnsmasq is a lightweight dns server that will fallback to the original DNS server when it encounters an unknown domain
Add the line address=/.your.domain.com/10.0.0.5 to the file /usr/local/etc/dnsmasq.conf
The IP Address 10.0.0.5 is whatever the IP address assigned to your local computer by your router. You can find this via Network Utility (if you want to be fancy, you can assign a static IP to your local computer in your router)
sudo dnsmasq
This starts dnsmasq process, and it will listen on the DNS ports
Assign your local computer and your router as your DNS servers for your computer via System Preferences -> Network -> Advanced -> DNS Tab
You'll have two entries, one for your local computer (127.0.0.1) and one for your router. The reason why you include your router's IP is dnsmasq will fulfill unknown entries through the other known DNS servers. Without the router entry, you're whatever devices connected to you dnsmasq won't know how to connect to the internet.
Set your local computer's IP Address as your DNS Server your iPhone, go to Settings -> Wi-Fi -> Info icon for your connected router -> DNS
Some things to consider:
If you shut down your machine, your iPhone won't connect to the internet anymore. Make sure to reset your iPhone's DNS server to your router's IP
By default dnsmasq will look at your /etc/hosts, so if you had pointed your.domain.com to 127.0.0.1, your iPhone will resolve your.domain.com to 127.0.0.1, which means you won't connect to anything. To change this behaviour edit uncomment the #no-hosts line in the dnsmasq config.
Sources
http://www.davesouth.org/stories/how-to-set-up-dnsmasq-on-snow-leopard-for-local-wildcard-domains
Set up a real DNS entry, either by setting up a local DNS server on your wireless network, or by using a dynamic DNS service, or by adding an A record to a domain you control DNS for.
You can also set up dnsmasq (available from macports/brew), it acts as a DNS forwarder which allows you to set all kinds of alternative records.
You can then set up the DNS on the iphone/ipad to point to the box running DNSmasq, and any host on /etc/hosts on the dnsmasq box will be returned first. If not found, dnsmasq will send the query to the upstream DNS.
Also you can add SRV records to dnsmasq.conf:
srv-host=_sip._udp.devel.foo.com,devel.foo.com,5070
And many other niceties.