Skip to content

Amazon Web Services

Jump to bottom
Mason J. Katz edited this page Feb 22, 2018 · 7 revisions

Amazon Web Services

NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.

Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).

Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.

The following table show the AMI's that are required.

OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044

Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.

Frontend

Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.

When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.

Once the Frontend is up and you can SSH in, you can start adding hosts.

Backends

Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:

{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.

Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.

When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.

What Next

Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.

Checkout our Google Group or our Slack Team for any support or other questions.

Want to contribute to this Wiki? Fork it and send a pull request.

Stacki Documentation

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Amazon Web Services · Teradata/stacki Wiki · GitHub
Skip to content
Amazon Web Services
Jump to bottom

Mason J. Katz edited this page Feb 22, 2018
·
7 revisions
Amazon Web Services
NOTE: This section is describing an unreleased feature of Stacki. The code isn't even on our git master branch. It works, it's cool, but it isn't released yet.
Stacki can also be installed inside Amazon EC2, and behaves very similar to standard bare-metal deployments. This guide assumes you already have an AWS account and are familiar with the AWS console or command line tools. You will need to know how to start instances and how to modify there settings (specifically the user data).
Stacki uses EBS volumes and HVM so the cloud environment is nearly identical to bare-metal. You can start and stop instances without data loss, you can even re-install backends the same way you do for bare-metal.
The following table show the AMI's that are required.
OSFrontendBackend
CentOSami-afbd5dd2ami-3e436044
SLESami-03ee087eami-3e436044
Note: the SLES Frontend AMI is not publicly available. The Backend AMIs are identical for both CentOS and SLES.
Frontend
Start a new instance of the Stacki Frontend AMI, for starting out we recommend the t2.xlarge instance type. Make sure to associate your SSH key with it or you will never be able to log in. The root account will be configured to accept your SSH key.
When the new Frontend starts it will spend several minutes completing the Stacki installation, so it may be up to 5 minutes after starting before you can log in. During this time the SSH service is running but it will not accept your key until after the installation completes.
Once the Frontend is up and you can SSH in, you can start adding hosts.
Backends
Start as many instances of the Stacki Backend AMI as needed, for starting out we recommend the t2.large instance type. Again you must associate your SSH key with the instance(s). You must also provide user data for each instance, this is how the new instances know where the Frontend is and can start the native operating system provisioner. This user data is a json structure:
{ "master" : "ipaddress of frontend" }

You can also specify the appliance type by adding "appliance" : "backend" to this structure (replace backend with your appliance). If nothing is specified the instance will install as a backend.
Because the instance is going to completely re-provision itself you can increase the disk size of the instance from the default size of the Backend AMI for more storage.
When the instance starts it will contact the Frontend to register intself and request profile. The Frontend will add the host (it will show up in stack list host) and the instance will install itself. At this point forward the installation looks just like bare-metal. When the installation is complete the instance will reboot, and you can log in over the private network or over the WAN using for SSH key.
What Next
Right now that's it. The goal here is to be as bare-metally as possible. Future directions may include using the Frontend to control AWS, but right now it doesn't even know it is running in the Cloud.
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally