I've recently upgraded an on premise Service Fabric cluster to 5.1.156.9590 running on Windows Server 2012 R2. I removed the original cluster and created a new one. Unfortunately my new cluster doesn't seem able to create the firewall rules for any ports specified in the service manifests. The only warning I see that seems connected is this from the ServiceFabric Hosting:
Did not enable firewallpolicy for current profile 1
I can't find any help regarding this message. I'm wondering if something has changed as regards specifying ports for a service or there's something on the node boxes that I haven't configured correctly.
Any pointers appreciated as I'm sure I didn't have to open them manually previously.
Unfortunately, I had the same problem and didn't succeed in reanimation of Service Fabric. Only moving to Azure helped to resolve the issue. You can try next things:
Completely remove SF, SDK, related services, firewall rules and directory SFData on C drive, then install everything again.
Check that firewall is enabled
Check that SF service is created and able to start
If the service is not able to start, check events, there is a special folder for SF where you can find additional and detailed infromation
If you have customized the address on which listeners will listen in SF cluster config, try to change it on something different and see if SF would deploy or not
Related
As a part of a project, setting up the litmus Chaos portal on the local machine is one of the requirements.
I could run the litmus Chaos frontend on on the localhost by following the below link: https://github.com/litmuschaos/litmus/wiki/Litmus-Portal-Development-Guide
In the above case we are starting the backend servers using kubectl commands.
But I am facing issues to set up my local environment such that I ll be able to start the backend servers on my local IDE(intellij for instance) without using kubectl commands.
It would be great if anyone could help me with this. Thank you in advance.
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 am having problem to access a node js rest service deployed on an ubuntu virtual machine. I am able to access the VM using putty, however I am not able to ping the reserve ip from command line. I have put the logs in the rest service as when it gets the hit it prints the log, the logs are not getting printed. I want to know if there is any additional setting which needs to be done to open a port from the virtual machine or it is supposed to be open by default. If I need to open the port in order to access the service, where should I look for it.
Thanks & Regards
I want to know if there is any additional setting which needs to be
done to open a port from the virtual machine or it is supposed to be
open by default.
No, Azure will not open other ports by default, we should open ports manually.
I am not able to ping the reserve ip from command line
It is a classic VM, am I right? if so, we should make sure the rest service listening on which port, and add endpoints via Azure portal:
More information about create an endpoint please refer to this link.
If your VM in ARM module, we should add a inbound rules to NSG.
More information about NSG, please refer to this link.
I have a certain number of hosts running different servers. All of them have nagios plugin installed. I wanted to write a script that would tell me daily if all the instances are up and running.
I tried opsview, but due to certain restrictions, I couldn't go ahead with it. It was then that I decided to use the nagios plugin directly. I thought about NRPE but it would be used to run a plugin remotely (provided you must know the address of the host), but in my case, I want to know if someone added a new server overnight, or some server failed or what all servers are running.
Nagios doesn't do discovery. You configure it with a list of machines and services to check.
Assuming we're talking about cloud servers, AWS can send you a message when a new server is added. See the doc The message can be SNS or SQS. These notifications could be read to rebuild your nagios configuration to match the auto-scale group.
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.