I have a domain that I bought in wix, Now I want to host my website in DIgital Ocean, How to connect droplet to wix domain
Yes.
Wix will probably use its name servers to ensure your domain's records are published. Wix provides a mechanism to manage your domain's records. You are able to add e.g. A, CNAME, TXT records.
See: Adding DNS records in your Wix account.
Droplets will generally be published on the Internet using IP(v4) addresses. You will want to add A(ddress) DNS records to alias your chosen host name in your domain to the Droplet's IPv4 address. For exmaple, to reference your droplet as droplet.[your-domain-name], you would create an A record with host name droplet with value set to the droplet's IP address.
Apps are published using SOMETHING.ondigitalocean.app (DNS) name. You will want to add CNAME DNS records to alias your chosen host name in your domain to the App's DNS name. For example, to reference your DigitalOcean Apps as app.[your-domain-name], you would create a CNAME record with host name app with value set to the app's SOMETHING.ondigitalocean.app name.
The default port for strapi is 1337, and default hostname is "Localhost".
I changed the hostname in the server.json file (that's inside the development folder) to "example.com" and saved that change.
However, when I start the program (by typing npm start in the terminal) although the output indicates that strapi is indeed hosting on "example.org" (and says the administration is at "example.org/admin"), upon navigating to example.org:1337, in a web browser, the page is not accessible. Yet, it is accessible when I navigate to localhost:1337.
I'm new to strapi. Any help will be appreciated. Thanks in advance!
Changing the domain name, inside of a server.json configuration file, won't likely result in your web browser being able to resolve that domain.
When your web browser tries to discover the IP address of a domain name, it first looks in your operating system's host file. If it cannot find the ip address of the domain there, it then tries to look for it at the DNS server that provides name-lookup for your local network.
DNS will typically point your domain to the public IP address of your web server and sometimes, if your web server is located on the same LAN you are, it can be tricky to teach the firewall or local DNS server how to route your browser's request within your LAN.
If you do edit your host file, to make the domain point to an internal IP address, you'll want to remove that entry later in order to access the domain when you are not on your LAN.
I write script that need to be used in different active directory forests.
In one forest I am able to use simple computer names that are the same as the computer samaccountname value.
mycomputername
In another forest I have to use dnshostnames that are normally shaped like
mycomputername.some.domain.path.com
Is this a forest setting and how can I identify this?
If you want to connect to a remote host by name you must be able to resolve the name (be it a hostname or FQDN) to an IP address. Whether you can resolve a hostname or need an FQDN depends on the search domains that are configured (or not configured) on a computer's network adapter.
I have a VPS server that only deals with email hosting. This server does not have any designated domain name pointing to it. Its only one VPS with one IP address.
I am running CentOS 6.5 Minimal, 32bit with Postfix and Dovecot installed. This is currently what my etc/postfix/main.cf looks like (for domain/hosting attributes).
# INTERNET HOST AND DOMAIN NAMES
#
# The myhostname parameter specifies the internet hostname of this
# mail system. The default is to use the fully-qualified domain name
# from gethostname(). $myhostname is used as a default value for many
# other configuration parameters.
#
myhostname =
#myhostname =
# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
mydomain =
# SENDING MAIL
#
# The myorigin parameter specifies the domain that locally-posted
# mail appears to come from. The default is to append $myhostname,
# which is fine for small sites. If you run a domain with multiple
# machines, you should (1) change this to $mydomain and (2) set up
# a domain-wide alias database that aliases each user to
# user#that.users.mailhost.
#
# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no #domain part.
#
#myorigin = $myhostname
myorigin = $mydomain
As you might have noticed, both myhostname & mydomain fields are empty. The reason for this is, the server doesn't really have a domain or hostname. What should I be doing in this case?
I have an M record pointing to mail.my-domain.tld and MX record pointing to mail.my-domain.tld
Can I use mail.my-domain.tld for both as mydomain = and myhostname = in main.cf? Because my-domain.tld is pointing to another VPS with another IP, which takes care of only web hosting.
myhostname - The internet hostname of this mail system. Here use mail.my-domain.tld
mydomain - The internet domain name of this mail system. The default is to use
$myhostname minus the first component.$mydomain is used as a default value for many other configuration parameters. So here use my-domain.tld
This VPS (mail server) can just serve your mail traffic and as you said your my-domain.tld web hosting can be in a different VPS server.
Hope that helps.
I successfully enabled PSRemoting on my Server 2008 R2.
I'm able to do a remote-pssession from within the same network using the hostname as target.
I'm failing when I try to use the IP-Address as target from any computer (within the network or from another network (for example via VPN)).
I want to be able to use remoting through my VPN connection where I have to use the IP-Address since the hostname can't be resolved.
I don't want to add names into my hosts-file because there are a few other servers at our clients' that have the same dns-name and I don't want to remove and insert the name-ip-address-association again and again.
I hope someone can tell me how to allow the psremoting-target to be called via IP.
Edit: To be more specific, I want to be able to run this:
Enter-PSSession -Computername 192.168.123.123 -credentials $cred
But I'm only able to run that command if I pass a hostname to "-Computername"
Edit2:
I'm getting following errormessage when I try to login using the ip instead of the hostname (from the internal network):
Enter-PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot process
the request. Default authentication may be used with an IP address under the following conditions: the transport is HT
TPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure T
rustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to se
t TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting
Help topic.
Edit3:
I know about the trusted-hosts setting of WSMan, but that doesn't seem to be the problem. It is already set to "*" (I did that right after enabling remoting), but I still can't connect to that server using the ip as target-computername, but I'm able to connect using the hostname as target-computername. Seems like there's something like the binding in IIS that prevents the listener to listen on requests that target the ip-number instead of the hostname. But IIS isn't installed. I don't know where to look for such a setting.
Update 2011-07-12:
Okay, I think that trustedhosts-setting is not the problem because I CAN connect from our DC via hostname but not if I use the ip-address of the destination for the computer-param.
I think, the problem must be the listener. Maybe the listener takes no requests that were targeted to the destination-ip instead of the destination-hostname. But I don't know how to change that.
The error message is giving you most of what you need. This isn't just about the TrustedHosts list; it's saying that in order to use an IP address with the default authentication scheme, you have to ALSO be using HTTPS (which isn't configured by default) and provide explicit credentials. I can tell you're at least not using SSL, because you didn't use the -UseSSL switch.
Note that SSL/HTTPS is not configured by default - that's an extra step you'll have to take. You can't just add -UseSSL.
The default authentication mechanism is Kerberos, and it wants to see real host names as they appear in AD. Not IP addresses, not DNS CNAME nicknames. Some folks will enable Basic authentication, which is less picky - but you should also set up HTTPS since you'd otherwise pass credentials in cleartext. Enable-PSRemoting only sets up HTTP.
Adding names to your hosts file won't work. This isn't an issue of name resolution; it's about how the mutual authentication between computers is carried out.
Additionally, if the two computers involved in this connection aren't in the same AD domain, the default authentication mechanism won't work. Read "help about_remote_troubleshooting" for information on configuring non-domain and cross-domain authentication.
From the docs at http://technet.microsoft.com/en-us/library/dd347642.aspx
HOW TO USE AN IP ADDRESS IN A REMOTE COMMAND
-----------------------------------------------------
ERROR: The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.
The ComputerName parameters of the New-PSSession, Enter-PSSession and
Invoke-Command cmdlets accept an IP address as a valid value. However,
because Kerberos authentication does not support IP addresses, NTLM
authentication is used by default whenever you specify an IP address.
When using NTLM authentication, the following procedure is required
for remoting.
1. Configure the computer for HTTPS transport or add the IP addresses
of the remote computers to the TrustedHosts list on the local
computer.
For instructions, see "How to Add a Computer to the TrustedHosts
List" below.
2. Use the Credential parameter in all remote commands.
This is required even when you are submitting the credentials
of the current user.
Try doing this:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
I test your assertion in my infrastructure the IP address is not the problem the following works for me :
PS C:\Users\JPB> hostname
JPBCOMPUTER
PS C:\Users\JPB> Enter-PSSession -ComputerName 192.168.183.100 -Credential $cred
[192.168.183.100]: PS C:\Users\jpb\Documents>
[192.168.183.100]: PS C:\Users\jpb\Documents> hostname
WM2008R2ENT
If you try to work accross a VPN you'd better have to have a look to the firewall settings on the way to your server. Installation and Configuration for Windows Remote Management can help you. The TCP port WinRM is waiting on are :
WinRM 1.1 and earlier: The default HTTP port is 80.
WinRM 2.0: The default HTTP port is 5985.
Edited : According to your error can you test this on youclient computer :
Set-Item WSMan:\localhost\Client\TrustedHosts *
The guys have given the simple solution, which will do be you should have a look at the help - it's good, looks like a lot in one go but it's actually quick to read:
get-help about_Remote_Troubleshooting | more
On your machine* run 'Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$ipaddress"
*Machine from where you are running PSSession
On Windows 10 it is important to make sure the WinRM Service is running to invoke the
command
* Set-Item wsman:\localhost\Client\TrustedHosts -value '*' -Force *
For those of you who don't care about following arbitrary restriction imposed by Microsoft you can simply add a host file entry to the IP of the server your attempting to connect to rather then use that instead of the IP to bypass this restriction:
Enter-PSSession -Computername NameOfComputerIveAddedToMyHostFile -credentials $cred
Please try the following on the client:
Run the following command to restore the listener configuration:
winrm invoke Restore winrm/Config
Run the following command to perform a default configuration of the Windows Remote Management service and its listener:
winrm quickconfig
After you configured winrm again, make sure host is trusted:
Set-Item wsman:\localhost\Client\TrustedHosts -value "$ipaddress" -Force
Try remote connect again
Reference
Configure winrm for HTTPS
I spend a great amount of time and finally got the solution. Following are the steps to do fix this -
Go to Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings in control panel
Make sure machine discovery in domain and guest is ON.
Open powershell in administrator mode on client machine and run winrm quickconfig and winrm set winrm/config/client '#{TrustedHosts="*"}'
As Don touched on this, here is more info
Using the IP is Kerberos authentication problem
If you are on a AD Domain and need a more elegant solution than allowing NTLM and trusted hosts: https://learn.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip
" Beginning with Windows 10 version 1507 and Windows Server 2016, Kerberos clients can be configured to support IPv4 and IPv6 hostnames in SPNs.
By default Windows will not attempt Kerberos authentication for a host if the hostname is an IP address. It will fall back to other enabled authentication protocols like NTLM. "
Note that there might be GPOs limiting / disabling NTLM in the domain - since this can be a security risk
To check run "RSOP".
GPOs are under: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies/Security Options > Network Security
Allowing basic auth and allowing "*" in Trusted hosts makes me cringe a bit :)
GL HF