As RSS has full internet firewall services built in (including DHCP and DNS), with routing, and supports simultaneous connections from multiple internet service providers: For most the easiest thing to do is connect your ISP’s modem/transceiver/etc directly to the ISP port on one of the RSS servers. Then, connect the ‘lan’ side to any of the available 1G or 10G connections. Convert any wifi base stations to ‘access point’ mode then either connect them to the lan ports. Or, for to provide restricted access, the one public access port on each server.
RSS will detect and register connections such as laptops and phones, and other servers automatically in local DNS, allowing you to designate special connections you choose as ‘devices’. Such will have fixed addresses across reboots, automatically get SSL certificates generated for them, registrations in LDAP and Kerberos, and be available across your locations with the same name. Handy for printers, multimedia ‘sticks’, capital/fixed equipment (scales, machine control, timeclocks, etc.)
Yes. You can plug an available ISP port on an RSS server into an existing LAN. You can even plug new or added ISP’s into other ISP ports on other RSS servers in the same cabinet. In such setups, the RSS features available over the public internet (cloud sync, websites, email, etc) will be available just as if the RSS system was the primary connection to the internet in a place with no changes necessary to the existing infrastructure. To allow other desktops, laptops and devices more direct RSS access (diskless booting, file access via SMB/windows shares/iSCSi, CephFS, etc) their connections will have to move from the existing setup to one of the lan ports on the RSS system.
Remember: to keep websites, sync and so on, that is full RSS functionality available even when the pre-existing ISP setup fails in a place, it is necessary to connect a second or further internet source to an available RSS ISP port (including cell phone ‘hotspot’ in a pinch).
Choosing this installation method is the least disruptive when there’s an existing infrastructure. So long as the existing ‘lan’ provides typical DHCP services to the internet, the standard used by Windows, Android, iOS and Linux devices, RSS will operate just fine. Generally after such setups are in place: device by device, existing subsystems that could benefit by the redundancy and capability of RSS get ‘migrated’ to the lan side of RSS. Whether that’s user/policy/admin setups, other file servers, workgroups etc. The last thing to go after moving lan connections from the pre-existing lan to one of the RSS lan connections is: connecting the ISP formerly feeding the pre-existing gateway/router directly to RSS then retiring/repurposing that device.
Yes. The public side of RSS (websites, email, cloud sync, etc) will operate normally for all connected systems whether on the public internet outside the location and also including those downstream of the connected gateway. The existing setup, now treating the RSS lan connection as ‘our new ISP’, will get the benefit of connectivity to the internet so long as at least one of the ISP’s connected to RSS is up (even a cell phone hot-spot in an emergency). However, only systems connected to the LAN side of RSS can access local services such as iSCSI, windows shares, CephFS, etc. Those ‘downstream’ of the existing internet-gateway will operate as before, just treating RSS as an ISP.
In such situations, step by step, systems connected ‘downstream’ of the existing firewall/gatewill will be connected to the LAN side of RSS. Until at last none are connected to the old firewall / gateway and it can be retired.
If your ISP currently provides a location a ‘static IP address’, and your existing firewall and existing systems depend on that: You can keep that setup with some configuration work (but still have your access depend on whether that one ISP is running). Better: transfer to RSS’s static addresses assigned to your location so your access will continue no matter which ISP or cell-phone hotspot is providing internet connectivity at each moment.
About the size of a dishwasher. There are five identical servers with a tremendous number of networking ports on the back of each one. So long as either the first or second is working, and not fewer than 3 of the 5 are working, your system is fully working. (All data is stored at least once on not fewer than three systems.)
- Four of the six 10G fiber ports per server are already occupied, they form the private internal backbone of the RSS setup, they direct connect each server to the remaining servers. There is no single point of failure, should one cable fail the traffic is routed via the remaining connections.
- One 1G copper typical full-duplex ethernet port per server is for a connection to an ISP.
- One 1G copper typical full-duplex ethernet port per server is to provide ‘guest access’, any switch or system connected via that port can access the internet but nothing local.
- The remaining two 10GB fiber capable ports, and four 1GB ethernet ports per server are available for LAN connections. As such, most RSS setups can retire several internet switches since RSS provides 8 10GB LAN ports and 16 1GB lan ports. While it is true should an RSS server fail those devices plugged directly into that one server will go offline (but not those connected to the other servers), that’s also true of any Ethernet switch as well. As RSS LAN ports cooperate in link-level topology management, some users may benefit from external switches connected to two or more RSS servers (reallocating the risk to the external switch). The RSS design reduces the risk as there are fewer cables and power supplies and ‘hops’ between the RSS setup and your client devices.
- What if you need a 10GB ISP port, or would like some other setup? Each server has a user editable table, you can pick which purpose should be provided via whichever port.
- By default, each system comes with 12TB of fully redundant user storage — all user data is stored three times, one each on one of the four RSS systems. Three LFF HDD slots are open per system for easy expansion.
- Each of the five servers includes a pair of mirrored system disks, reserved for RSS code, virtual machine images and related system purposed, non-user information. Each system has at least 128GB memory, and at least two E5-2670v2 XEON class cpu’s or better.
- The “IPMI” or “KVM” management ports on the first four systems are connected to the 5th system, usually dedicated to admin and special purposes. That system has a keyboard, mouse and screen connected to it that sits atop the cabinet. The admin system is there as a hot spare, in a pinch it can replace one of the primary four.
- Each of the systems has several USB ports, but their use is discouraged as anything connected via a USB port can only work so long as that particular system is running.
- Any wifi base station connected to the LAN or public access port of RSS should be set up as an access point only. No routing or gateway functions.
- Every system comes fully pre-configured with all the system software described on this website. While all those features are fully available at all times, customized for your internet domain and location– none of them use resources if not used. They are ‘all there, ready and waiting’ but never ‘in the way’.
All that’s necessary to link up to 15 locations, as if they were all in the same building, is to install at least an RSS minimal system in one of them, then at least a two server version in any of the secondary locations to support at least two ISP’s and be able to keep going should one system fail. Locations with no need for multiple ISP’s for high availability, no local printers or devices to share with other locations can use the native “VPN” or “Road warrior” access methods (using WireGuard as the VPN).
If your needs are for a lot more general purpose capacity (more of everything), up to 7 multiple purpose servers can work within a location (meaning you’d like each server to ‘do a little bit of everything’, including file server, email server, web server, ISP host, etc. etc.). After that the RSS 10GB backbone supports up to 50 additional web servers per location, same for email and most other dedicated capabilities.
Notice that’s entirely separate from the hundreds of possible dedicated devices, services and extensions you can add to the lan that RSS will make available to all locations as if local (but not the public internet).
While the minimal system uses or re-uses servers that are a couple years old to provide a cost effective sweet spot, the system is fully capable as-is of using the most advanced and fastest servers on the market today. If you need speed and want to throw the latest at it, every subsystem is fully rated for it and has a team of support specialists ready and able to extend the RSS base in whatever the direction of your need.
RSS is designed to permit servers ‘in the cloud’ to act as if internal resources. It’s an easy way to add capacity for short-term projects. Of course, servers ‘in the cloud’ put any data at greater security risk, so it’s often much easier just to add another server within an existing RSS setup.
Well, as you might have guessed — It’s all designed in and managed automatically with no static IPs required of any ISP. Whether any of the ISP’s connected to an RSS system have dynamic or static numeric internet addressing, do or don’t support IP version 6: Those parts of the RSS system meant to deliver information over the internet based on fixed DNS addresses such as maintained by domain name registrars work, all the time, no matter which ISP happens to be working at this or that RSS location at the moment. Here’s a general look at how that’s done.
Staff and systems using RSS requesting information from the public internet, such as news, movies, general browsing and so on, have their traffic routed directly through whichever ISP is working at that location. Just as if there was a typical little router/gateway box connecting them. This design allows streaming services providing movies, and others that rely features specific to your ISP at your location direct unfettered access, with no delays or extra ‘hops across the net’.
However, requests that originate outside the RSS system, requests from the public for access to information that your setups choose to offer (such as websites, cloud sync, email, video chat, etc.), those are routed to static IPs assigned to each client per location, both IP4 and IP version 6, via one of two data centers– one of which is under miles of rock in Missouri, both of which have backup generators and all the usual high-service, high-security data-center abilities (See Bluebirdnetwork.com for more details). RSS maintains servers at each of those centers that encrypts the traffic with wireguard, then routes traffic to whichever ISP’s currently provide service at any RSS client location (Road-warrior/VPN access works this way too). Most clients will get those services from RSS. As an added benefit, clients that need IP version 6 and it’s huge number of free IP addresses can get it via RSS even if their ISPs only provide IP version 4.
There is not one byte of your or anyone else’s data stored in the RSS routing systems in the cloud. They’re just routers with only enough storage to boot and lots of processing power. They collect inbound traffic then send it on to the correct RSS client location via whatever ISPs are up at that moment at each client location, then collect the replies generated at your location’s RSS system then pass that back to the folks looking for info your site has chosen to share. Neither more nor less safe than the best available routers powering the internet today. It’s your location’s ‘fixed P.O. box address on the internet’ — the web browsing and similar initiated by users within each location doesn’t use the RSS cloud routers at all, just the local ISPs up at the moment.
By arrangement, it is possible for larger clients to own, operate and manage those routing systems in-house.
The prior design is going on 10 years. Over that period, five hard drives were replaced as were two entire servers of the group. Today’s RSS minimal entry-level system is built, currently, on Supermicro X9 systems and the latest in subsystem software. That could change based on availability but the performance will be that or greater. Faster / newer / more servers would be more, but only for the hardware.
That’s the whole point. Yes. If when the power fails at a location nobody can work there whether the computers are still working or not, then installing RSS at several locations will keep the websites up even if the power should fail at one of them. If you have multiple locations set up for business reasons anyway, with RSS there’s no pressing reason to purchase and maintain backup generators, long term battery systems and so on. While your maximum service speed will be reduced when a location is offline, overall your systems will still be ‘up’. It’s best to have an odd number of locations set up in this case.
We’re all about new relationships both from organizations with in-house basic IT skill-sets and IT service/support organizations.
For organizations with non-specialist internal IT skills, we provide a pre-customized turn-key solution starting at around $12K delivered. Expect a roughly 45 day lead time for North American clients. We really mean ‘turn key’– all the network, software, systems engineering is done. There’s a GUI for everyday-everything, and a technical interface for your in-house IT talent.
If you’re an IT house looking to deepen long-term client relationships: The minimal system is available to you as a base, or you can manage the hardware acquisition and setup. Either way, we’ll remotely install pre-customized software ready for you to extend, manage and deliver to your clients.
RSS passes along hardware and network traffic fees at cost. Extensive paid and free, remote and on-site support and education organizations exist for all major RSS subsystems. There are no fees for open-source software components. RSS’s income is from the physical integration effort, the networking and system layout architecture, and the non-open-source RSS software (rssmonitor) which is included on every ‘bare-metal’ and ‘virtual machine’ cooperating to form an RSS system. Rssmonitor manages installation, automates scale/size changes, reallocates resources on failures, and actively monitors the health and provides ongoing linkage/updates/integrations among the servers, certificates, and software sub-systems.
Also, for those systems using RSS’s cloud routers as their ‘routing/post-office’ for inbound website/sync and email traffic: there are some ongoing pass-along fees, in proportion to the volume of the network traffic. (Note as RSS routes typical web browsing and movie/streaming traffic directly via the local ISP(s), that traffic doesn’t flow through RSS’s cloud routers and so does not add cost).
Further fees depend on whether the client wants to manage subsystem updates in-house or have RSS staff manage them, wants updates to the rssmonitor system, or requires training from RSS.
To get started, send an email to frontdesk@rockstablesystems.com or call 563-650-7800.
“Too long, didn’t read”: No single point of failure, the whole cloud located within affordable department / office locations, multi-ISP support, attention to scale, 10K+ lines of python, Ceph, Alma/RedHat, Ubuntu/Debian, Freeipa, Nextcloud, WordPress, Nginx, HAProxy, Android, Apple, Windows, KEA, Bind9, Email, web-hosting, databases, video conferencing, mobile file/photo sync + redundant storage, calendars, KVM, Libvirt, Dovecot, Postfix, MariaDB, Galera, SIP, DNSSEC, WebRTC, STUN, TURN, Kerberos, LDAP, SSL, Certificates, SSH, NTPSec, Chrony, Gerbera, GIT, Eclipse, Autofs, Nftables, WireGuard, VPN, Sync, some security stuff only documented to clients, Wireshark, Selinux, Apparmor, Spamaassasin, Spamhaus, Samba, PHP, Redis, Git, Freeswitch, — and the dozens of sub-packages required by them, 5 rack-mounted servers in dishwasher sized cabinet or less, up to racks and racks, and, etc.
Hopefully, that should help you justify more reading time! For more, see the rest of this website.