In a manner of a short overview: I've begun to study the development of the FreeBSD 10 AMI for the Amazon Web Services (AWS) Elastic Compute Cloud (EC2), with an interest firstly in contributing to the documentation about the matter, secondly an interest in developing a functional instance of the AMI.
In regards to documentation formats, I'd noticed that the FreeBSD documentation project has been a topic, here in the forums. I'm certainly interested in contributing to the documentation tree. Personally, I'm familiar with the DocBook format, in its XML and SGML editions at DocBook 4, and the RELAX NG Compact (RNC) XML schema of DocBook 5. I've also begun to study the Darwin Information Typing Architecture (DITA) XML format, as well as TeX and the LaTeX macro package for TeX -- referring to Safari Books Online, for documentation about those technical documentation formats. Personally, I prefer the topically focused XML structure of DITA -- though the DITA tools are relatively "Scarce" in free/open source software, but it seems to me that it may serve as an ideal kind of technical documentation format. Furthermore, I think DITA may transition well from a sort of ad hoc "Itemized list" documentation format -- such as in keeping work logs and design documents, in Evernote notes. Of course, I understand that most of the FreeBSD documentation is developed in a DocBook format. Time allowing, it would be definitely possible to develop a DocBook to DITA transformation, whether in a format of XML Stylesheets or in any more informal sense.
Presently, I'm stuck at a matter of a "Long way around" towards developing a self-hosted WordPress server on a FreeBSD OS in the AWS EC2 cloud.
Aside to the topic of documentation formats:
Personally, I've created an EC2 instance of the FreeBSD 10 AMI, to a successful "First boot". Concerning the IP addressing of the instance, as well as the PF configuration in the instance, I'd noticed that the instance is configured -- by default -- to use DHCP for its IP addressing. In short, I have now successfully configured the EC2 instance such that it cannot be accessed over the public Internet. The "DOH!" moment has passed, though, and I am now trying to understand how the AMI's user data feature may be applied for creating an effective rc.conf such that would configure a static IP address for the instance.
I've allocated an Elastic IP address at AWS, and have assigned the Elastic IP address to the instance via the AWS Management Console. In short, this has created a public IP address such that can be assigned to the instance, for configuring the network interface 'xn0' on the instance, such that the instance would then be accessible via a public, static IP address. Otherwise, the instance would be accessible in its VPC subnet, as via a dynamic, public IP address such that may change on each reboot of the instance -- thus complicating the SSH configuration for accessing the instance, furthermore somewhat as it being complicating to the PF configuration or other packet filter configuration for the instance.
I have tried to configure the EC2 instance via its EC2 instance user data field, such that I had hoped that the configinit scripting in the instance would 'ifconfig xn0 {my_ip}/32' on reboot -- such that I would then be able to access the EC2 instance via the public internet, without having to rebuild the instance entirely. The documentation about how the EC2 user data field is applied, though detailed to some extent, is not exactly a complete documentation, and I'm not certain if I've understood how the configinit syntax for rc.conf is designed.
Although I'm not very far along with the initial build of the instance -- thus, it would not require a lot of time, to rebuild the instance and hopefully to not reproduce this "Inaccessible Instance" condition thus -- but in the interest of documenting this process, I hope it may be possible to find any manner of support about this IP addressing concern.
I would apologize if my style of writing may seem difficult to read, in a sense. The following text represents a verbatim copy of the user data that I've applied to the EC2 instance:
xn0 is a network interface evidently deriving of the Xen architecture, as applied in AWS. It's the primary network interface for the instance.
To my best estimate, the last change that I had made within the instance's internal rc.conf -- such that seems to have made it inaccessible, somehow -- was to add this setting to the immediate rc.conf configuration:
After adding that change, I then ran:
Subsequently, the instance became unreachable from the public network. Previous to that change, I had made some changes to the instance's pf.conf, such as to allow UDP bootps traffic "out" too all hosts on the subnet, and to allow UDP bootpc traffic "in" from the specific host that was the first to respond to the initial DHCP request. I had reloaded the pf configuration after that change, to no result of any manner of an interruption in service. It was not until the addition of the
I am not presently much concerned about the DHCP configuration, albeit. I believe I've begun to understand how to configure a static IP address for the EC2 instance. My concern is that (1) "It's not working", as in that the instance is booting but I cannot access it via the public network, though (2) I've provided what I had thought was an appropriate ifconfig, via the user-data field on the respective EC2 server instance.
If anyone can help me to understand why it's not working, candidly I am fairly confused about what's the hangup in the configuration but I would appreciate any manner of advice about the configuration.
Ideally, it could be tremendously easy for people to use FreeBSD with AWS -- whether in a laboratory environment, a development sandbox environment, or a full production environment -- in any kind of a "Just press play" configuration. The details of it, though -- there's the place for documentation, I think?
Beginning a manner of a bibliography about this single issue-tracking item:
I expect that I'll have to rebuild the EC2 instance -- not a tasking effort, so early in the instance's configuration. Certainly, I'll be making a backup copy of the EC2 instance, before any further such configuration changes.
I hope that I may be able to understand why it "Stopped working," in this instance. Candidly, I already have a working FreeBSD image at Digital Ocean. I had hoped it would be easier to transition to AWS.
The user data configinit feature -- it's throwing me. If it is not all like a multiple choice question, I wonder: Do I have the syntax of it correct?
Updated: "Oh," but maybe there is the gateway address that the AWS management layer has created, in all its veritable SDN mesh. Somehow, the VPC addressing scheme may seem fairly transparent -- that an AWS Elastic IP address, for instance, has both of a public IP address and a private IP address, the latter probably being what I should wish to assign to the xn0 interface -- transparent, in a sense, except for the matter of trying to find an exact subnet gateway address however allocated in AWS for a VPC subnet.
Moreover, there may be up to a day's delay between signing up for the AWS forums and being able to actually ask a question there -- it would seem to suggest I should wish to be in the Enterprise Support lane, instead?
In regards to documentation formats, I'd noticed that the FreeBSD documentation project has been a topic, here in the forums. I'm certainly interested in contributing to the documentation tree. Personally, I'm familiar with the DocBook format, in its XML and SGML editions at DocBook 4, and the RELAX NG Compact (RNC) XML schema of DocBook 5. I've also begun to study the Darwin Information Typing Architecture (DITA) XML format, as well as TeX and the LaTeX macro package for TeX -- referring to Safari Books Online, for documentation about those technical documentation formats. Personally, I prefer the topically focused XML structure of DITA -- though the DITA tools are relatively "Scarce" in free/open source software, but it seems to me that it may serve as an ideal kind of technical documentation format. Furthermore, I think DITA may transition well from a sort of ad hoc "Itemized list" documentation format -- such as in keeping work logs and design documents, in Evernote notes. Of course, I understand that most of the FreeBSD documentation is developed in a DocBook format. Time allowing, it would be definitely possible to develop a DocBook to DITA transformation, whether in a format of XML Stylesheets or in any more informal sense.
Presently, I'm stuck at a matter of a "Long way around" towards developing a self-hosted WordPress server on a FreeBSD OS in the AWS EC2 cloud.
Aside to the topic of documentation formats:
Personally, I've created an EC2 instance of the FreeBSD 10 AMI, to a successful "First boot". Concerning the IP addressing of the instance, as well as the PF configuration in the instance, I'd noticed that the instance is configured -- by default -- to use DHCP for its IP addressing. In short, I have now successfully configured the EC2 instance such that it cannot be accessed over the public Internet. The "DOH!" moment has passed, though, and I am now trying to understand how the AMI's user data feature may be applied for creating an effective rc.conf such that would configure a static IP address for the instance.
I've allocated an Elastic IP address at AWS, and have assigned the Elastic IP address to the instance via the AWS Management Console. In short, this has created a public IP address such that can be assigned to the instance, for configuring the network interface 'xn0' on the instance, such that the instance would then be accessible via a public, static IP address. Otherwise, the instance would be accessible in its VPC subnet, as via a dynamic, public IP address such that may change on each reboot of the instance -- thus complicating the SSH configuration for accessing the instance, furthermore somewhat as it being complicating to the PF configuration or other packet filter configuration for the instance.
I have tried to configure the EC2 instance via its EC2 instance user data field, such that I had hoped that the configinit scripting in the instance would 'ifconfig xn0 {my_ip}/32' on reboot -- such that I would then be able to access the EC2 instance via the public internet, without having to rebuild the instance entirely. The documentation about how the EC2 user data field is applied, though detailed to some extent, is not exactly a complete documentation, and I'm not certain if I've understood how the configinit syntax for rc.conf is designed.
Although I'm not very far along with the initial build of the instance -- thus, it would not require a lot of time, to rebuild the instance and hopefully to not reproduce this "Inaccessible Instance" condition thus -- but in the interest of documenting this process, I hope it may be possible to find any manner of support about this IP addressing concern.
I would apologize if my style of writing may seem difficult to read, in a sense. The following text represents a verbatim copy of the user data that I've applied to the EC2 instance:
Code:
>>/etc/rc.conf
network_interfaces="xn0 lo0"
ifconfig_xn0="inet 52.33.46.66/32"xn0 is a network interface evidently deriving of the Xen architecture, as applied in AWS. It's the primary network interface for the instance.
To my best estimate, the last change that I had made within the instance's internal rc.conf -- such that seems to have made it inaccessible, somehow -- was to add this setting to the immediate rc.conf configuration:
Code:
dhclient_flags_xn0="-v"After adding that change, I then ran:
Code:
service netif restartSubsequently, the instance became unreachable from the public network. Previous to that change, I had made some changes to the instance's pf.conf, such as to allow UDP bootps traffic "out" too all hosts on the subnet, and to allow UDP bootpc traffic "in" from the specific host that was the first to respond to the initial DHCP request. I had reloaded the pf configuration after that change, to no result of any manner of an interruption in service. It was not until the addition of the
dhclient_flags setting that the EC2 instance became notably unreachable.I am not presently much concerned about the DHCP configuration, albeit. I believe I've begun to understand how to configure a static IP address for the EC2 instance. My concern is that (1) "It's not working", as in that the instance is booting but I cannot access it via the public network, though (2) I've provided what I had thought was an appropriate ifconfig, via the user-data field on the respective EC2 server instance.
If anyone can help me to understand why it's not working, candidly I am fairly confused about what's the hangup in the configuration but I would appreciate any manner of advice about the configuration.
Ideally, it could be tremendously easy for people to use FreeBSD with AWS -- whether in a laboratory environment, a development sandbox environment, or a full production environment -- in any kind of a "Just press play" configuration. The details of it, though -- there's the place for documentation, I think?
Beginning a manner of a bibliography about this single issue-tracking item:
- The subnet mask for AWS Elastic IP public IP addresses is, apparently, 255.255.255.255 [AWS Discussion Forums] thus, in a kind of CIDR dotted-quad notation NDD.NDD.NDD.NDD/32
- AWS has developed an entire orchestration framework for so much as subnetting in Software Defined Networking (SDN) applications with AWS - viz a viz Amazon EC2 Instance IP Addressing, in the EC2 Linux docs, and primarily in referencing the AWS Virtual Private Cloud (VPC) User Guide
I expect that I'll have to rebuild the EC2 instance -- not a tasking effort, so early in the instance's configuration. Certainly, I'll be making a backup copy of the EC2 instance, before any further such configuration changes.
I hope that I may be able to understand why it "Stopped working," in this instance. Candidly, I already have a working FreeBSD image at Digital Ocean. I had hoped it would be easier to transition to AWS.
The user data configinit feature -- it's throwing me. If it is not all like a multiple choice question, I wonder: Do I have the syntax of it correct?
Updated: "Oh," but maybe there is the gateway address that the AWS management layer has created, in all its veritable SDN mesh. Somehow, the VPC addressing scheme may seem fairly transparent -- that an AWS Elastic IP address, for instance, has both of a public IP address and a private IP address, the latter probably being what I should wish to assign to the xn0 interface -- transparent, in a sense, except for the matter of trying to find an exact subnet gateway address however allocated in AWS for a VPC subnet.
Moreover, there may be up to a day's delay between signing up for the AWS forums and being able to actually ask a question there -- it would seem to suggest I should wish to be in the Enterprise Support lane, instead?
