I am trying NosDB, created database cluster on single node, and than added second node in my database cluster, but I am failing with error message, "Add-Shard : Login 'asif_mehmood' does not exist".
Steps I perforemd:
Installed NosDb OpenSource on two boxes.
Created cluster with one shard on first box, using New-DatabseCluster powershell cmmdlet.
Added another shard with second box as node, using Add-shard powershell cmdlet.
Failed with following error Message
Add-Shard : Login 'asif_mehmood' does not exist
At line:1 char:1
+ Add-Shard -Name shard2 -Server 192.168.0.15 -Port 2250
For adding other node in database cluster, both nodes should be in same domain or on same work group,
before adding second node in database cluster, add login of current box on second box using Add-Login cmmdlet with following parameters
Username: username of second box windows login
Password: Password for above
Server: IP of second box,
After adding login second node was added successfully in database cluster.
Related
(I'm afraid I'm probably about to reveal myself as completely unfit for the task at hand!)
I'm trying to setup a Redshift cluster and database to help manage data for a class/group project.
I have a dc2.large cluster running with either default options, or what looked like the most generic in the couple of place I was forced to make entries.
I have downloaded Aginity (Win64) as it is described as being specialized for Redshift. That said, I can't find any instructions for connecting using it. The connection dialog requests the follwoing:
Server: using the endpoint for my cluster (less :57xx at the end).
UserID: the Master username for the database defined for the cluster.
Password: to match the UserID
SSL Mode (Disable, Allow, Prefer, Require): trying various options
Database: as named in cluster setup
Port: as defined in cluster setup
I can't get it to connect ("failed to establish connection") and don't know if I'm entering something wrong in Aginity or if I haven't set up my cluster properly.
Message: Failed to establish a connection to 'abc1234-smtm.crone7m2jcwv.us-east-1.redshift.amazonaws.com'.
Type : Npgsql.NpgsqlException
Source : Npgsql
Trace : at Npgsql.NpgsqlClosedState.Open(NpgsqlConnector context, Int32 timeout)
at Npgsql.NpgsqlConnector.Open()
at Npgsql.NpgsqlConnection.Open()
at Aginity.MPP.Common.BaseDataProvider.get_Connection()
at Aginity.MPP.Common.BaseDataProvider.CreateCommand(String commandText, CommandType commandType, IDataParameter[] commandParams)
at Aginity.MPP.Common.BaseDataProvider.ExecuteReader(String commandText, CommandType commandType, IDataParameter[] commandParams)
--- Inner Exception: ---
......
It seems there is not enough information going into Aginity to authorize connection to my cluster - no account credential are supplied. For UserID, am I meant to enter the ID of a valid user? Can I use the root account? What would the ID look like? I have setup a User with FullAccess to S3 and Redshift, then entered the UserID in this format
arn:aws:iam::600123456789:user/john
along with the matching password, but that hasn't worked either.
The only training/tutorial I have been able to find/do on this is the Intro AWS direct you to, at https://qwiklabs.com/focuses/2366, which uses a web-based client that I can't find outside of the tutorial (pgweb).
Any advice what I am doing wrong, and how to do it right?
Well, I think I got it working - I haven't had a chance to see if I can actually create table yet, but it seems to be connected. I had to allow inbound traffic from outside the VPC, as per the above snapshot.
I'm guessing there's a better way than opening it up to all IP addresses, but I don't know the users' (fellow team members) IPs, and aren't they all subject to change depending on the device they're using to connect?
How does one go about getting inside the VPC to connect that way, presumably more securely?
I'm testing using a gMSA account to run an SF app, instead of NETWORKSERVICE.
Following the instructions from here:
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-runas-security
Created the gMSA on the domain controller using the powershell cmdlet:
New-ADServiceAccount -name MySA$ -DnsHostName MySA.contoso -ServicePrincipalNames http/MySA.contoso -PrincipalsAllowedToRetrieveManagedPassword Node0Machine$, Node1Machine$, Node2Machine$
Install-AdServiceAccount returned an "unspecified error" on each of the nodes, however Test-AdServiceAccount returns true for MySA$ (when running powershell as a domain user)
ApplicationManifest.xml has the following changes:
<Principals>
<Users>
<User Name="MySA" AccountType="ManagedServiceAccount" AccountName="Contoso\MySA$"/>
</Users>
</Principals>
<Policies>
<SecurityAccessPolicies>
<SecurityAccessPolicy ResourceRef="ConfigurationEncipherment" PrincipalRef="MySa" ResourceType="Certificate" />
</SecurityAccessPolicies>
<DefaultRunAsPolicy UserRef="MySA"/>
</Policies>
The Service Fabric explorer shows the following error for each service:
Error event: SourceId='System.Hosting', Property='CodePackageActivation:Code:SetupEntryPoint'.
There was an error during CodePackage activation.Service host failed to activate. Error:0x8007052e
I have also tried creating the cluster using the gMSA (we are using X509 successfully at the moment). Using the gMSA cluster config as a template, it fails with a timeout (presumably the "WindowsIdentities section is incorrect - there seems to be little documentation on this)
"security": {
"WindowsIdentities": {
"ClustergMSAIdentity": "MySA$#contoso",
"ClusterSPN": "http/MySa.contoso",
"ClientIdentities": [
{
"Identity": "contoso\\MySA$",
"IsAdmin": true
}
]
},
The Error:0x8007052e may be linked to a logon failure.
According to Secure a standalone cluster on Windows by using Windows security and Connect to a secure cluster
If you have more than 10 nodes or for clusters that are likely to grow or shrink. Microsoft strongly recommend using the Group Managed Service Account (gMSA) approach.
You will see also:
You can establish trust in two different ways:
Specify the domain group users that can connect.
Specify the domain node users that can connect.
[...]
Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services.
You may also find help on Getting Started with Group Managed Service Accounts
According to your comment, as soon as you add the gMSA to the ServiceFabricAdministrators group everything will work and it is probably due to the fact that "administrators have full access to management capabilities"
I create a subnet before i create an instance by python script.
def subnet_create(self, network_id, **kwargs):
params = {'name': kwargs.get("name"),
'cidr': kwargs.get("cidr"),
'ip_version': 4,
'enable_dhcp': True}
body = {'subnet': {'network_id': network_id}}
body['subnet'].update(params)
return self.neutron_client.create_subnet(body=body).get("subnet")
after that i create an instance by code:
compute_srv = self.nova_cli.instance_create(
compute_inst["name"],
compute_inst["image"],
compute_inst["flavor"],
key_name=compute_inst["key_name"],
user_data=compute_inst["user_data"],
security_groups=compute_inst["security_groups"],
nics=compute_inst["nics"])
the horizon shows the subnet and the instance was created successfully, but when i open the console page, sometimes the terminal shows that the instance cannot attach to the metadata server:
calling 'http://169.254.2169.254/2009-04-04/metadata/instance-id' failed
the current instance can not ping the subnet gateway, but instance from other subnet can ping this instance.
This problem is not present every time. some other times it may shows the instance has attached to the metadata server， and the hostname、ip address can set right.
But when i create the subnet manually by horizon,the instances always able to connect the metadata server.
I so confused, and i have stuck here for about a whole week.Does anyone knows why? Thank you very much.
I received a FAILED Server error, status code: 500, error code: 10001,
message: Service broker error : {"description"=>"Service Broker provisioned at this url state is not operational 10002"} message, when trying to create a new SQLDB service instance.
What is the issue?
I was able to confirm that there was a brief issue earlier with the "Free" plan but it has since been resolved.
I was able to create a service successfully from the CF command line:
$ cf create-service sqldb sqldb_free randalstTestSQLDB515
Creating service randalstTestSQLDB515 in org johndoe#myemail.com /
space dev as johndoe#myemail.com...
OK
Try to create the service from the command line using the following syntax:
$ cf create-service sqldb sqldb_small mySQLDB
where
The first attribute sqldb is the service name.
The second attribute is the plan, either sqldb_small, sqldb_free, or sqldb_premium.
The last attribute mySQLDB is the unique name that you are giving to this service instance.
I'm performing REST API operation Start Role (http://msdn.microsoft.com/en-us/library/jj157189.aspx)
In the link https://management.core.windows.net/{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations we have replaced {service-name}, {deployment-name} and {role-name} with name of VM.
In result we have next message:
"ResourceNotFoundThe resource service name hostedservices is not supported."
List Hosted Services operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460781.aspx) shows us that we have 2 WMs as hosted services.
Get Role operaion (http://msdn.microsoft.com/en-us/library/jj157193.aspx) also gives info about each of VMs.
Thanks in advance.
You are using:
{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations
But the correct Uri is:
{subscriptionID}/services/hostedservices/{serviceName}/deployments/{deploymentName}/roleInstances/{roleInstanceName}/Operations
See the difference?
I haven't worked with this particular operation, however a few things:
service-name: It should be the name of the hosted service (the one with .cloudapp.net) and what you see when you list your hosted service.
deployment-name: Generally speaking it's a GUID returned by Get Deployment operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460804.aspx).
role-name: Role name is also returned when you do a Get Deployment operation. You should use that. I'm not sure if it is same as the name of your VM.
Can you retry your operation after changing these values?
In my case, deployment name is the name of the first VM I created in this cloud service. So, if I added 3 machines to the same cloud service, all of them have the same deployment name - the name of the first machine.