I am porting some Windows code to Linux. Part of the windows objects properties was not implemented in .net core's linux implementation. UnicastIPAddressInformation.PrefixOrigin is one of them.
.NET Core code docs show define it as:
value that identifies the source of a unicast IP address prefix.
MSDN defines it as:
Specifies how an IP address network prefix was located.
I am searching .NET Core repo browser for the implementation of this property, which returns the following enumeration:
public enum PrefixOrigin
{
Other = 0,
Manual,
WellKnown,
Dhcp,
RouterAdvertisement,
}
I could not find in .NET Core repo browser a class that implements UnicastIPAddressInformation. In .NET Framework repo browser, I understand the struct IdAdapterUnicastAddress is assigned a PrefixOrigin by marshaling OS data into C# classes/types. Anyway, I do not know at this point how to determine which enumeration value should be applied to a given IP.
Knowing barely nothing about computer networks, I am researching what is an IP prefix and how to figure it out. The practical example I could find was this one. As far as I understand, however, it provides a way to calculate the prefix length. I still need to know how to determine the PrefixOrigin enumeration value to a given IP.
Is it something that can be done by simply taking the prefix length into account ? If not, how do I figure out which PrefixOrigin value a given IP should be assigned ?
This field's value is telling you how a configured (or automatically-configured) IP address on the system was determined.
Manual: Somebody keyed it into the adapter configuration GUI in control panel or set it using e.g. netsh or similar.
Well Known: From a well-known source. I'm not really sure if Windows uses this value. It might be used when a 169.254.x.x address is assigned in the absence of any other configuration and when no DHCP server is present.
DHCP: When a DHCP server automatically assigns an IP address, which is the case in almost all home and office networks (but sometimes not on datacenter networks!), this is how you can tell.
Router Advertisement: IPv6 has an automatic configuration system which was supposed to replace DHCP. To keep things simple, think of this as being functionally the same as the field's DHCP value.
Is it possible to create ip groups in some way? so I can provide træfik with something like this: traefik.frontend.whiteList.sourceRange=MyGroup.
I would love to not worry about which ips I give access to when deploying a new service, but rather just provide a group and know that someone else is in control of managing the list of that group.
You can specify a source range in CIDR notation. To whitelist all local network IPs from 192.168.0.0 to 192.168.255.255, for example:
traefik.frontend.whiteList.sourceRange=192.168.0.0/16
Here's a handy helper for getting the right notation: CIDR Calculator
If you want to whitelist single IPs only, you can use a comma separated list, limiting the range to a single IP address with /32:
traefik.frontend.whiteList.sourceRange=1.2.3.4/32,2.3.4.5/32
In nginx, in order to listen on a specific interface (on a dual-homed server) you must declare the interface via IP address. Obviously this isn't scalable in a Chef recipe, as you can't have the IP be static but instead point to the server's interface. Is there a way to achieve this?
Chef uses Ohai to gather information about the system. The simple form is node['ipaddress'] which is generally the IP corresponding to the interface with the default route. This might not always be what you want though, so we also have a hash of all interface under node['network']['interfaces'] where you can iterate over them, find the interface you want, and grab its address. Run ohai | less from the command line to see all the data available to you.
I am not good with Ohai. I would like to know if there is any way to find out all ip address (including own) of nodes from respective subnet through Chef recipe.
I have created one layer in AWS Opswork and want to add each node's ip addr and hostname in the configuration file. Any help will highly appreciated.
So this depends a little bit on if you want to get all the instances in a layer, or all the total instances in your stack.
For the first, something like this - untested! - code for your recipe should work:
my_layer_name = "my_database_layer_or_whatever"
node[:opsworks][:layers][my_layer_name][:instances].each do |current_instance, current_instance_data|
puts node[:opsworks][:layers][my_layer_name][:instances][current_instance][:private_dns_name]
end
Note that this will get you the private dns name - so internal to the OpsWorks network. You may or may not want that - there are a dozen or so other attributes on the object, including the public IP address.
If you wanted to get instances for the entire stack, I'm betting you could loop through node[:opsworks][:layers], as I've looped through the instances here. Just another loop.
Also note this code is for Chef 11. In Chef 12 things have changed a bit.
If you're using Chef 12, I found the documentation on how to use/search the Chef Data Bags for OpsWorks.
When developing an app that will listen on a TCP/IP port, how should one go about selecting a default port? Assume that this app will be installed on many computers, and that avoiding port conflicts is desired.
Go here and pick a port with the description Unassigned
First step: look at IANA listing :
There you will see at the tail of the list
"The Dynamic and/or Private Ports are those from 49152 through 65535"
so those would be your better bets, but once you pick one you could always google on it to see if there is a popular enough app that has already "claimed" it
If by widely-used, you mean you want to protect against other people using it in the future, you can apply to have it marked as reserved for your app by IANA here
The most comprehensive list of official IANA port numbers and non-official port numbers I know is nmap-services.
You probably want to avoid using any ports from this list (Wikipedia).
I would just pick one, and once the app is used by the masses, the port number will become recognized and included in such lists.
Choosing an unassigned one from the IANA list is usually sufficient, but if you are talking about a commercially-released product, you really should apply to the IANA to get one assigned to you. Note that the process of doing this is simple but slow; the last time I applied for one, it took a year.
As others mention, check IANA.
Then check your local systems /etc/services to see if there are some custom ports already in use.
And please, don't hardcode it. Make sure it's configurable, someway, somehow -- if for no other reason that you want to be able to have multiple developers using their own localized builds at the same time.
If this is for an application that you expect to be used widely, then register a number
here so no-one else uses it.
Otherwise, just pick an unused one randomly.
The problem with using one in the dynamic range is that it may not be available because it may be being used for a dynamic port number.
Well, you can reference some commonly used port numbers here and try not to use anyone else's.
If by "open to the public at large" you mean you're opening ports on your own systems, I'd have a chat with your system administrators about which ports they feel comfortable with doing that with.
Choose a number that is not very common
Choose a default port that doesn't interfere with the most common daemons and servers. Also make sure that the port number isn't listed as an attack vector for some virus -- some companies have strict policies where they block such ports no matter what. Last but not least, make sure the port number is configurable.
Use iana list. Download the csv file from :
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv
and use this shell script for searching for unregistred ports:
for port in {N..M}; do if ! grep -q $port service-names-port-numbers.csv; then echo $port;fi; done;
and put 2 numbers instead of N and M.