Imperfect initial commit, but too far to go back
This commit is contained in:
commit
06f37260ec
50
Classes/Artemis_Bridge_Simulator_Mod.md
Normal file
50
Classes/Artemis_Bridge_Simulator_Mod.md
Normal file
@ -0,0 +1,50 @@
|
||||
This group is dedicated to playing [http://artemis.eochu.com/ Artemis Spaceship Bridge Simulator], learning teamwork to overcome challenges and improve communication, within a fun, science-fiction atmosphere.
|
||||
|
||||
# About the Game
|
||||
|
||||
## Instructions to Install
|
||||
* If you are an [[User:DarkFeather/Sandbox#Stations|LO]], purchase [http://artemis.eochu.com/index.php/buy-the-game/ a bridge license] and download the 2.4.0 installer -- otherwise, get a copy of the installer from your captain.
|
||||
* Install Artemis for all users on your system.
|
||||
* Get a copy of the mod from [https://aninix.net/share/mod.zip the AniNIX].
|
||||
* Copy the contents of the mod to "C:\Program Files (x86)\Artemis\dat". You should be prompted whether you want to replace files; confirm the replacement.
|
||||
* Launch Artemis from "C:\Program Files (x86)\Artemis\Artemis.exe". You should see yellow LCARS-like buttons rather than the standard blue and advanced models.
|
||||
|
||||
## Stations
|
||||
Every ship requires a commanding crew; while it is possible to command a ship alone, greater challenges can be beaten with a crew. Each crew should strive for a five-person command staff, though if a crew is short personnel some stations may be overloaded. The LO will be be one such position that's always overloaded.
|
||||
* Helm: The helm officer (HO) controls the course and speed of the ship, managing maneuvering, impulse, and warp or jump drives. Helm also has access to shield and mainscreen control. All vessels require a HO.
|
||||
* Weaponry: The weapons officer (WO) controls all weaponry onboard. They are in charge of loading or unloading torpedo tubes and phaser targeting. All vessels require a WO.
|
||||
* Engineering: The engineering officer (EO) controls power distribution throughout the ship for all systems and the damage control teams.
|
||||
* Science: The science officer (SO) is in charge of gathering information and managing the sensors. Science provides shield harmonics to the WO and a course to the HO.
|
||||
* Captain: The captain is in charge of coordinating the other officers and monitoring communications.
|
||||
* Licensing: These individuals have purchased a bridge license. To accomodate the developer's licensing requests, each crew should have at least one licensing officer (LO). This position should overloaded with another station.
|
||||
* Commander Air Group: The CAG is in charge of the fighter stations on board vessels with a fighter complement. This station may be overloaded or a dedicated one on carrier-class vessels.
|
||||
|
||||
## Backstory
|
||||
Multiple timelines have converged as a shared threat in the temporal cold war. The nexus is a stellar nursery. The Federation [http://memory-alpha.wikia.com/wiki/Starfleet Starfleet] has led the charge to prevent damage to the timeline, and now both factions have setup up a dense network of stations in the stellar nursery, supported by civilians. The opposing factions have been raiding the border, and temporal operatives from Starfleet have contacted other factions for help. It is still unknown who is leading the opposing factions against Starfleet, though there is suspicion of an [http://memory-beta.wikia.com/wiki/Iconian Iconian] influence.
|
||||
|
||||
Allied factions:
|
||||
* [http://memory-beta.wikia.com/wiki/Romulan_Republic Romulan Republic]
|
||||
* [http://memory-alpha.wikia.com/wiki/Klingon_Empire Klingon Empire]
|
||||
* [https://en.wikipedia.org/wiki/Ranger_(Babylon_5) Rangers]
|
||||
* [http://firefly.wikia.com/wiki/Independent_Planets Independent Planets]
|
||||
* [http://en.battlestarwiki.org/wiki/The_Fleet_(TRS) Colonial Fleet]
|
||||
|
||||
Opposing factions:
|
||||
* [http://memory-alpha.wikia.com/wiki/Orion_Syndicate Orion Syndicate]
|
||||
* [http://memory-alpha.wikia.com/wiki/Dominion Dominion]
|
||||
* [http://memory-alpha.wikia.com/wiki/Borg_Collective Borg Collective]
|
||||
* [http://memory-alpha.wikia.com/wiki/Cardassian_Union Cardassian Union]
|
||||
|
||||
Native (and hostile) species to the nursery:
|
||||
* [http://artemiswiki.pbworks.com/w/page/100481081/Space%20Dragon The Dragon Race]
|
||||
* [http://artemiswiki.pbworks.com/w/page/99813681/BioMech%20Stage%204 The Biomechs]
|
||||
|
||||
# Roster
|
||||
|
||||
## LOs
|
||||
* Mark Jambor
|
||||
* Connor Ford
|
||||
|
||||
## Static Crews
|
||||
|
||||
## Enlisted Personnel
|
42
Classes/Games_Team-building_Exercise.md
Normal file
42
Classes/Games_Team-building_Exercise.md
Normal file
@ -0,0 +1,42 @@
|
||||
This is in support of team-building between [[TeamRed]] and [[TeamBlue]] staff, or any other group. ARGs like [http://www.seekadventureapp.com/ Seek] and puzzle rooms also offer good opportunities, but this paradigm works for a geodiverse staff. It's good to use these games as a kick-off to penetration testing, as a way to familiarize the teams with each other's communication styles before given their assignments.
|
||||
|
||||
The AniNIX domain has rules in its [[AniNIX::Shadowfeed]] to support running these simulations. Geodiverse teams may want to use TeamSpeak, Discord or Skype for voice relay.
|
||||
|
||||
# Team Purple Anectdote
|
||||
Some organizations have noticed a tendency in red-team and blue-team crews to become combative with one another. Sites in this situation have found it useful to randomly shuffle the teams between assignments, so that personnel operate as a mixed "Team Purple", with red- and blue-team prefixes only applicable to the individual assignment.
|
||||
|
||||
# Basis
|
||||
A number of recent scifi series have been focusing on small crews operating out of a mobile fully-complete base of operations, a starship. This makes for a very interesting model -- real-world penetration testing teams may use small Sprinter-style vans rigged with a complete [[Service_and_Host_Layout|AniNIX clone domain]] onboard, rigged into the roof. Living space can be rigged in the back with the crew riding forward.
|
||||
|
||||
Some example shows include:
|
||||
* [http://www.imdb.com/title/tt0374455/?ref_=nv_sr_2 StarGate Atlantis]
|
||||
* [http://www.imdb.com/title/tt4159076/?ref_=fn_al_tt_1 Dark Matter]
|
||||
* [http://www.imdb.com/title/tt0244365/?ref_=fn_al_tt_1 Star Trek: Enterprise]
|
||||
|
||||
## Space-based naval engagements
|
||||
Space operations are supplied by the [http://artemis.eochu.net/ Artemis Starship Bridge Simulator]. Crews operate a starship in scenarios and naval battle simulations with diverse roles.
|
||||
|
||||
## Ground special operations
|
||||
Ground operations are supplied by the [https://unvanquished.net/ Unvanquished freeware]. This is a mixed base building and small-team game -- TeamBlue will operate with classic Human ranged weapons, while TeamRed aliens focus on melee attacks and unconventional warfare.
|
||||
|
||||
# Example layout
|
||||
Here we have some basic layouts to provide structure for the operation -- creative teams can add their own story and intrigue. Space operations require more coordination than ground operations, but here are the default roles. Additional teammates can be added as generic infantry/fighterpilot roles.
|
||||
|
||||
* Commanding officer: Starship engineer and ground engineer
|
||||
* Executive Officer: Starship weapons officer and ground heavy weapons specialist
|
||||
* Intel Agent: Science/Comms officer and ground overwatch
|
||||
* Specialist: Starship helmsman and ground recon infantryman
|
||||
|
||||
:<b>Note</b>: If any team is to be at a numerical disadvantage, it should be TeamRed. TeamBlue should have 1-2 more players in unbalanced scenarios. This lets them rush on the ground while protecting their base and to use fighter support in space combat to intercept nuclear weapons. Artemis is particularly vulnerable to weak weapons officer getting overwealmed and missing an incoming nuke, while Unvanquished also has trouble with phase balancing between the teams allowing well-timed rushes. This weighting thus matches real-world manpower discrepancies.
|
||||
|
||||
## TeamBlue onboard the TSS Nakhimov
|
||||
Named for [https://en.wikipedia.org/wiki/Pavel_Nakhimov Admiral Pavel Nakhimov], Team Blue operates out of a warp-drive [http://artemiswiki.pbworks.com/w/page/107290305/TSN%20Juggernaut Terran juggernaut] with a [https://wiki.unvanquished.net/index.php?title=Humans human away team]. These crews should focus on maintaining close unit integrity and defensive base security, slowly marching the whole of their firepower into range with a well-researched strategy. Strong coordination and well-rehearsed close-quarters procedures keep the crew alive and out of TeamRed's easy reach.
|
||||
|
||||
## TeamRed onboard the XSS Qahirah
|
||||
Named for the [https://en.wikipedia.org/wiki/Abbasid_Caliphate Abbasid conquerors'] capital now known as Cairo, Team Red operates out of a jump-drive [http://artemiswiki.pbworks.com/w/page/107286384/Ximni%20Battleship Ximni battleship] with an [https://wiki.unvanquished.net/index.php?title=Aliens alien away team]. These crews should focus on unconventional ambush tactics -- ground crews should use early dretch units to probe for weaknesses, focusing on picking off stragglers with predatory tactics later. In space, the scanning abilities of the ship should be used to identity gaps in the cover being used by TeamBlue to make calculated jumps.
|
||||
|
||||
## AI Support
|
||||
Individual teams can manage team-building exercises for their role with Artemis scenarios and Unvanquished [https://wiki.unvanquished.net/index.php?title=Navigation_Meshes navmesh bots] to take the place of the other team.
|
||||
|
||||
|
||||
[[Category:Class]][[Category:Security]]
|
80
Classes/White-hat_Demo.md
Normal file
80
Classes/White-hat_Demo.md
Normal file
@ -0,0 +1,80 @@
|
||||
I want to emphasize the importance of cybersecurity by showing how a few bad practices can disclose supposedly secure information. Moreover, I want to emphasize the tools that
|
||||
|
||||
# This Demo is Not...
|
||||
* How to hack your friend’s FaceBook
|
||||
* How to become an evil hacking mastermind
|
||||
* How to control the Matrix
|
||||
|
||||
# Materials
|
||||
* Control of Wifi network and wifi's DNS, if using physical hardware, or some method of controlling routing.
|
||||
* Demo computer (VM or physical)
|
||||
* For easy installation, install [[ShadowArch#How_to_Install_ShadowArch|ShadowArch]] with a graphical environment and a Holocron layout.
|
||||
* Run the following. This Makefile is viewable in [https://aninix.net/foundation/ConfigPackages the ConfigPackages git repo]. <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo democlient</pre>
|
||||
* You will still need to sync /etc/hosts with the demo server.
|
||||
* Users can access a virtualized demo client with VNC over [[SSH]].
|
||||
* Demo server with lighttpd, telnet server, ftp server, OpenSSH server, Wireshark.
|
||||
* For easy installation, install ShadowArch with the GUI option, and run the following: <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo demoserver</pre>
|
||||
* Lighttpd should be configured with both unsecured and secured traffic.
|
||||
* Lighttpd will need one URL that is auth protected -- simple auth is sufficient.
|
||||
* There should be a remote-capable user "testuser" with a preset initial password.
|
||||
* You should also sync /etc/hosts with any demo clients.
|
||||
* [https://www.kali.org/ Kali Linux] iso -- if you're using physical hardware for the demo, use a [[Holocron]] flashdrive
|
||||
* A demo user with a read-write VNC view of the democlient, a pentester with physical access to the server and client, and a class with read-only VNC sessions watching the client.
|
||||
|
||||
# Exercises
|
||||
## Account Credentials
|
||||
<!-- This should be updated to be a BurpSuite assault -->[[Category:TODO]]
|
||||
* An obviously dumb password should be set in the server's /etc/lighttpd/.lighttpdpassword and disclosed to the demouser.
|
||||
* The pentester "guesses" the password and discloses why it's weak.
|
||||
* Talk about [http://www.businessinsider.com/how-to-create-strong-password-heartbleed-2014-4 strong passwords].
|
||||
### Mobile PIN Break
|
||||
* Talk about how PINs are important
|
||||
* Talk about guessing pins from smudges
|
||||
* Financial data, email accounts, text messages, and such are all accessible.
|
||||
* Talk about [https://en.wikipedia.org/wiki/Phishing phisihing] via a captured phone with SMS
|
||||
## Encrypted network traffic
|
||||
The key takeaway is to encrypt all network traffic. While a [https://en.wikipedia.org/wiki/VPN VPN] and similar network encryption models help, these tools are very simple and controllable.
|
||||
### Browsers
|
||||
[https://en.wikipedia.org/wiki/SSL SSL] allows us to validate that we are talking to the site we expect to.
|
||||
* Use wget to mirror a login page to the demo server. The Makefile defaults to facebook.com.
|
||||
* Redirect the traffic to unsecured traffic
|
||||
* Have the demo user connect to the site over unsecured HTTP.
|
||||
* Have a user connect to the same site over HTTPS and see the warning message.
|
||||
* Optionally, remove the diverted routing and have the user reconnect to the site over HTTPS without seeing the warning.
|
||||
* Capture traffic on [https://www.wireshark.org/ Wireshark] and ask the demo user to confirm their password in the capture.
|
||||
* Talk about SSL chain of trust.
|
||||
|
||||
SSL encryption also prevents capturing session information.
|
||||
* Have the demo user go to the demoserver's web server over unsecured HTTP.
|
||||
* The root page will have a POST HTML form.
|
||||
* Use Wireshark to capture the data and show the TCP stream.
|
||||
* Have the demo user repeat the process over HTTPS.
|
||||
* SSL will prevent following the stream.
|
||||
|
||||
### Telnet/FTP
|
||||
* Have the demo user reset his password on the server with telnet.
|
||||
* Capture traffic with Wireshark and show the password.
|
||||
* Have the demo user pull down a file over FTP, change it, and put it back up.
|
||||
* Capture traffic with Wireshark and show the change.
|
||||
* Explain SFTP/SSH correlation to HTTPS -- encryption matters.
|
||||
|
||||
## Storage bypass w/ iso
|
||||
[https://wiki.archlinux.org/index.php/Disk_encryption Disk encryption] makes it harder to access data. While physical access is death, strong encryption can delay access beyond heat death of the universe, which is long enough.
|
||||
* Have the demo user set the root password and add a file in /root.
|
||||
* Power off the machine and have the pentester take control.
|
||||
* Ask the class if the files are secure.
|
||||
* Boot the machine with the iso instead and find the file.
|
||||
* Optionally, set the root password and boot the original system.
|
||||
* Talk about encrypted storage and how this recovery would be harder.
|
||||
### File recovery
|
||||
Just because a system has files deleted from it doesn't mean that the data is lost.
|
||||
* dd 0's onto small partition on demo server
|
||||
* Create ext4 filesystem
|
||||
* Have the demouser create a file, display its contents, and delete it.
|
||||
* The pentester "steals" the hardware and boots with a Kali iso
|
||||
* Run "extundelete <disk> --restore-all -o /root" to recover the file
|
||||
* Talk about secure deletion with shred or similar programs and the added difficulty of disk encryption.
|
||||
|
||||
|
||||
[[Category:Class]]
|
||||
[[Category:Security]]
|
25
Entities/Bastion.md
Normal file
25
Entities/Bastion.md
Normal file
@ -0,0 +1,25 @@
|
||||
A Bastion host is a gateway to accessing other hosts. It is a safeguard against admin error.
|
||||
|
||||
# Etymology
|
||||
Bastion hosts are named because they are the first line of defense against administrative error -- they prevent admins from being locked out of correcting their changes.
|
||||
|
||||
# Capacity and Components
|
||||
A Bastion host needs minimal CPU or memory.
|
||||
|
||||
# Hosted Services and Entities
|
||||
Nothing is hosted by a Bastion.
|
||||
|
||||
# Connections
|
||||
See [[:Category:Entity|the entity list]] -- any host should be able to connect to a Bastion with [[SSH]] and X11, and it should be able to dial to any service provider.
|
||||
|
||||
# Additional Reference
|
||||
Bastion hosts should be deployed alongside any Hypervisor and set to start on boot. The encrypted credentials volume should be encrypted per [[ShadowArch]]'s recommendations, and it should not be added to /etc/fstab or /etc/crypttab.
|
||||
|
||||
To create a Bastion:
|
||||
1. Create a new VM in the Hypervisor and mark it to start on boot. For an example Hypervisor, see [[Forge2]].
|
||||
1. Install ShadowArch with the Spartacus layout and without encryption or GUI -- encryption complicates boot and GUI is unnecessary. Applications with GUI will be X11-forwarded.
|
||||
1. Log in as root and convert the exfat partition from the Spartacus layout to an encrypted ext4 or xfs one.
|
||||
1. "make -C /usr/local/src/ConfigPackages/Bastion install"
|
||||
1. Log in as the bastion user on the new VM and run new-ssh-key for each [[SSH]]-capable host.
|
||||
1. Set a NAT rule in the router to allow access to the Bastion host on a non-22 port.
|
||||
}}
|
45
Entities/Core.md
Normal file
45
Entities/Core.md
Normal file
@ -0,0 +1,45 @@
|
||||
The Core is the central VM on which the AniNIX's primary services are built. It is both a production platform and software repository location.
|
||||
|
||||
# Etymology
|
||||
The Core is so named because all the rest of the AniNIX is built around it.
|
||||
|
||||
# Capacity and Components
|
||||
The AniNIX is a [[ShadowArch]][[Category:ArchLinux]] installation. It receives the following resources from [[Forge2]]:
|
||||
* 4 Cores
|
||||
* 8GB RAM
|
||||
* Virtualized GPU
|
||||
* 2TB storage
|
||||
* USB device assignment
|
||||
* Virtual bridged network interface
|
||||
* Bluetooth adapter passthrough
|
||||
* CD/DVD drive
|
||||
* BluRay drive
|
||||
|
||||
# Hosted Services and Entities
|
||||
{{Reference|Aether}}{{Reference|Cerberus}}{{Reference|Foundation}}{{Reference|Grimoire}}{{Reference|Heartbeat}}{{Reference|IRC}}{{Reference|TheRaven}}{{Reference|Singularity}}{{Reference|Sora}}{{Reference|SSH}}{{Reference|WebServer}}{{Reference|Wiki}}{{Reference|WolfPack}}{{Reference|Yggdrasil}}
|
||||
|
||||
# Connections
|
||||
{{Reference|Shadowfeed}}{{Reference|Eyes}}{{Reference|Windows}}{{Reference|DarkNet}}
|
||||
|
||||
# Additional Reference
|
||||
## Storage stack
|
||||
The AniNIX uses the following storage stack, from user-accessed files to bits on disk. Bootability is from an unencrypted [https://wiki.archlinux.org/index.php/EXT4 EXT4 boot sector] and MBR [https://wiki.archlinux.org/index.php/GRUB GRUB] bootloader.
|
||||
* Files
|
||||
* [https://wiki.archlinux.org/index.php/XFS XFS Filesystem]
|
||||
* LUKS volume
|
||||
* LVM physical volume
|
||||
* 2TB Physical disk
|
||||
|
||||
The output of "lsblk -o NAME,KNAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABEL,PARTLABEL" gives the following layout. Additional shares mounted to accomodate users are not shown.<pre>
|
||||
NAME KNAME SIZE FSTYPE TYPE MOUNTPOINT LABEL PARTLABEL
|
||||
sda sda 1.8T disk
|
||||
├─sda1 sda1 500M ext4 part /boot COREBOOT
|
||||
└─sda2 sda2 1.8T LVM2_member part
|
||||
├─corestorage-coreswap dm-0 10G crypto_LUKS lvm
|
||||
│ └─coreswap dm-3 10G swap crypt [SWAP]
|
||||
└─corestorage-core dm-1 1.8T crypto_LUKS lvm
|
||||
└─sysroot dm-2 1.8T xfs crypt /
|
||||
sr0 sr0 1024M rom </pre>
|
||||
}}
|
||||
|
||||
[[Category:LDAP]]
|
26
Entities/DarkNet.d/Free_Internet_Practices.md
Normal file
26
Entities/DarkNet.d/Free_Internet_Practices.md
Normal file
@ -0,0 +1,26 @@
|
||||
In the wake of the catastropic [http://money.cnn.com/2017/12/14/technology/fcc-net-neutrality-vote/index.html FCC vote to kill Net Neutrality], [[DarkNet|privacy VPN]] machines may become more prevalent to allow unfettered and uncensored access to the Internet. In the meantime, some less-drastic measures can be taken to help allow access to fettered, deprioritized, slow-laned, or censored traffic.
|
||||
|
||||
Please visit the #freenet channel on [https://aninix.net/irc/ AniNIX::IRC] with questions or suggestions.
|
||||
|
||||
# Recommendations
|
||||
These settings are mostly for good encryption to prevent eavesdropping and good compression of traffic to better tolerate throttled links.
|
||||
* Install Google Chrome.
|
||||
* Turn on [https://chrome.google.com/webstore/detail/data-saver/pfmgfdlgomnbgkofeojodiodmgpgmkac?hl=en-US Data Saver] in your [chrome://extensions extensions].
|
||||
* Android users may find this inside Chrome under the triple-dot icon at the top right.
|
||||
* Conduct a security review of Chrome as a best practice against ISP eavesdropping and deep packet inspection (which can be used for throttling or controlling your traffic).
|
||||
* Check under [chrome://settings Chrome's settings] > "Advanced" > "Privacy and Security" to make sure the settings meet your need. We strongly encourage the "Protect you and your device from dangerous sites" and 'Send a "Do Not Track" request with your browsing traffic' options.
|
||||
* Visit [https://myaccount.google.com/security?pli=1 myaccount.google.com/security] to run an account audit.
|
||||
* Set up Google Authenticator or other two-factor solutions.
|
||||
* Disable automatically downloading updates and instead patch machines weekly or when they're being shutdown. **Note: we strongly encourage patching! Make sure that you regularly check for patches.**
|
||||
* Windows users can do this by following [[Forge2#Windows Update|these instructions]] under the Windows Update header.
|
||||
* Linux users should make sure to download patches at night and perhaps share package files from a central package cache.
|
||||
* Android users can do this from the Google Play store under Settings > Auto-update apps.
|
||||
* Coordinate large downloads to occur during minimum usage hours. This is dependent on sysadmin analytics.
|
||||
* Install Tor Browser to access censored content.
|
||||
* Windows users can download from [https://www.torproject.org/download/download.html.en Tor].
|
||||
* Android users can install [https://play.google.com/store/apps/details?id=info.guardianproject.orfox Orfox] and [https://play.google.com/store/apps/details?id=org.torproject.android Orbot].
|
||||
* Set "Compression yes" in ~/.ssh/config. Older clients may need to additionally add "CompressionLevel 8".
|
||||
|
||||
# Fight Back
|
||||
* We still have a widget added to the WebServer root to allow you to continue to petition Congress against the FCC's decision.
|
||||
* [https://techcrunch.com/2017/12/14/new-york-attorney-general-announces-a-multi-state-lawsuit-challenging-the-net-neutrality-vote/ Several states are suing.] Stay informed through [https://www.eff.org/ EFF] and [https://battleforthenet.com/ BattleForTheNet], and contribute where you can.
|
26
Entities/DarkNet.md
Normal file
26
Entities/DarkNet.md
Normal file
@ -0,0 +1,26 @@
|
||||
The DarkNet VM is the privacy protection of the AniNIX. The AniNIX does not believe in security by obscurity or in censorship; as such, everyone should have a voice.
|
||||
|
||||
# Etymology
|
||||
The DarkNet is named for an anonymous network whose access is controlled only by the admins and whose usage is known only to them. It's entirely closed and anonymous.
|
||||
|
||||
# Capacity and Components
|
||||
* [[ShadowArch]]
|
||||
* 1 core
|
||||
* 1024M of RAM
|
||||
* 150G of storage
|
||||
* Virtualized NIC
|
||||
|
||||
# Hosted Services and Entities
|
||||
The DarkNet uses a small package list but runs more than the standard ShadowArch install. Also included are the xfce4, xorg-server, tor-browser-en(AUR), transmission-gtk, transmission-cli, and openvpn packages.
|
||||
## Abilities
|
||||
* Encrypted storage by default to a passphrase known only to admins.
|
||||
* Tor proxy service, integrated with both text lynx and GUI tor-browser-en browsers.
|
||||
* Lynx is aliased to "torsocks lynx" globally
|
||||
* Anonymous VPN via OpenVPN (details available on request)
|
||||
<!-- we use cryptostorm[d0t]is with prepaid Visas purchased with cash -->
|
||||
## Hosted
|
||||
{{Reference|WolfPack}}{{Reference|VirusScan}}
|
||||
|
||||
# Connections
|
||||
{{Reference|Core}}
|
||||
}}
|
88
Entities/Forge2.md
Normal file
88
Entities/Forge2.md
Normal file
@ -0,0 +1,88 @@
|
||||
The Forge2 is the primary hardware platform on which the AniNIX runs.
|
||||
|
||||
# Etymology
|
||||
The Forge2 the second Forge build, the original having been two towers instead of one.
|
||||
|
||||
It is so named because the exterior is solid black with soft red LED's internally -- this creates an appearance similar to a furnace.
|
||||
|
||||
The Forge builds are also so named because projects are created, developed, and tested in these frames.
|
||||
|
||||
# Capacity and Components
|
||||
* 6-core hyperthreaded core i7 at 3.4GHz, water-cooled by Corsair H100i two-fan cooler
|
||||
* 24 GB RAM
|
||||
* 13.2 TB onboard storage. One hotswap slot open.
|
||||
* 60 GB solid state boot drive for Windows 10 Pro Hypervisor (Hyper-V)
|
||||
* 1 1TB drive dedicated to additional user space and VM's
|
||||
* 1 2TB drive dedicated to Windows data formatted as NTFS
|
||||
* 1 2TB drive dedicated to Windows Backup formatted as NTFS
|
||||
* 2 2TB drive dedicated to [[Core|AniNIX::Core]] -- see Core for the filesystem hierarchy there.
|
||||
* One hotswap bay for [[Aether|AniNIX::Aether]] backups.
|
||||
* 1 150GB drive for the [[DarkNet]] VM
|
||||
* USB 2.0 & 3.0 and eSATA slots
|
||||
* 2 10GB NIC's -- one for VM's and one for Windows
|
||||
* Bluetooth Adapter
|
||||
* Hyper-V virtualization under Windows 10 Pro[[Category:Microsoft]]
|
||||
* 1200W Corsair power supply
|
||||
* EVGA x79 Dark motherboard with PCI-e SATA extender
|
||||
* SLI'ed GTX 760 GPU's with 4GB onboard cache each
|
||||
* Corsair K70 Keyboard w/ red LED and Corsair M65 mouse.
|
||||
* CyberPower UPS
|
||||
[[Category:Corsair]]
|
||||
[[Category:EVGA]]
|
||||
[[Category:Intel]]
|
||||
[[Category:Seagate]]
|
||||
[[Category:Kingston]]
|
||||
|
||||
# Hosted Services and Entities
|
||||
{{Reference|Core}}{{Reference|Windows}}{{Reference|DarkNet}}
|
||||
|
||||
# Connections
|
||||
{{Reference|Infrastructure}}{{Reference|Shadowfeed}}{{Reference|Core}}{{Reference|Windows}}
|
||||
|
||||
# Additional Reference
|
||||
## Gallery
|
||||
A gallery will be added. [[Category:TODO]]
|
||||
}}
|
||||
# Hypervisor Notes
|
||||
Hyper-V integrates VM's with Windows, allowing VM's to be started at Windows boot, providing direct disk access, and managing assignment of cores, memory, and disk.
|
||||
|
||||
ShadowArch guests with a GUI should include xf86-video-fbdev and set GRUB_CMDLINE_LINUX_DEFAULT="quiet video=hyperv_fb:1920x1080" to get maximum screen resolution.
|
||||
|
||||
Hyper-V comes with a few limitations. PCI and USB devices can't be passed through without 3rd-party software, but this was considered acceptable.
|
||||
|
||||
Hyper-V guests require significant configuration to prevent performance problems. Dynamic memory should be disabled to prevent a guest from overrunning the host. Data Exchange, Backup, and Guest Services should all be disabled from integration services. Disable checkpoints. Automatic start action should either be on startup or disabled, and automatic stop action should always be poweroff.
|
||||
|
||||
Hyper-V itself also requires configuration of the Windows host. The default High Performance power profile turns off monitors when not in use but does not put the entire frame to sleep -- this is the desired behavior.
|
||||
|
||||
## Antivirus
|
||||
Make sure Hyper-V, if using [[VirusScan|antivirus]] follows the [[VirusScan#Hyper-V|Hyper-V considerations]].
|
||||
|
||||
Presently, this still caused drops in virtual disks, crashing several VM's, so we are suspending antivirus on the hypervisor, along with most general-purpose browsing. Read the following for other user experiences.
|
||||
1. https://www.cnet.com/how-to/i-dont-use-anti-virus-software-am-i-nuts/
|
||||
1. https://www.reddit.com/r/windows/comments/41b0k0/is_antivirus_software_still_necessary_for_windows/
|
||||
|
||||
## Windows Update
|
||||
The Windows Update service, if it deems the system too out of date or in need of critical fixes, may forcibly restart the system. We recommend keeping the Windows Update service disabled on hypervisors until patching is desired. This can be done in services.msc.
|
||||
|
||||
We recommend addtionally setting the "gpedit.msc > Computer Configuration \ Administrative Templates \ Windows Components \ Windows Update \ Configure Automatic Updates" option if you have a Pro or Enterprise license.
|
||||
|
||||
## Sleep Mode
|
||||
Sleep mode, even immediately interrupted, has been observed to break network connectivity and VM uptime. When running as a Hypervisor, it is advisable to disable sleep and hibernate modes. Change these from Group Policy under Administrative Templates>System>Power Management>Sleep Settings. Enable "Turn Off Hybrid Sleep" and disable "Allow Standby States (S1-S3) when sleeping".
|
||||
|
||||
## Previous Hypervisors
|
||||
### VirtualBox
|
||||
Oracle VirtualBox is a free hypervisor that can run on almost any OS. This makes deployment and device driver management entirely on the stock OS, which was Windows in our case thus alleviating driver problems. Management is also easy, particularly with an admin account, so it's easy to assign cores, memory, and such to a VM. VirtualBox can assign raw disk access with VBoxManage. Use Windows Disk Manager (diskmgmt.msc) to identify the disk. In the case below, 7 is the disk number.
|
||||
<pre>"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" internalcommands createrawvmdk -filename "C:\Users\Admin\VirtualBox VMs\raw7.vmdk" -rawdisk \\.\PhysicalDrive7</pre>
|
||||
|
||||
VirtualBox was dropped due to buggy integration with the running OS and the inability to start VM's at OS Boot.
|
||||
### ArchLInux/KVM-enabled KVM
|
||||
The Forge2 frame has a 60GB SSD installed for KVM-enabled QEMU virtualization inside a minimal ArchLinux host. This implementation allows passing any host resources to the guest, including USB and PCI devices which is an advantage over other Hypervisors.
|
||||
|
||||
While Intel VT-d provided by the motherboard ostensibly supports this passthrough, it had hardware caps on the x79 that the AniNIX could not afford (4 hard drives, 1 CD drive) without disabling KVM, and the network bridging created problems for VPN clients.
|
||||
|
||||
# Alternatives
|
||||
You could in theory put the hardware for an AniNIX network clone in the Cloud. There are steps to set up ArchLinux in [http://codito.in/archlinux-on-azure/ Microsoft Azure] and [https://bbs.archlinux.org/viewtopic.php?id=186707 Google Cloud]. This may be advantageous for sites that have uptime concerns, low local resources, or physical security concerns.
|
||||
|
||||
From a cost perspective, power and network for a Forge2 and [[Shadowfeed|AniNIX::Shadowfeed]] costs roughly $100 per month with a $6000 buy-in. Equivalent cloud solutions would need to supply at least one full backup image with highly available power and network, along with [[Forge2#Capacity and Components|equivalent capacity]].
|
||||
|
||||
You should look at [[Aether|AniNIX::Aether]] notes on cloud computing if you consider this as an option.
|
50
Entities/Forge3.md
Normal file
50
Entities/Forge3.md
Normal file
@ -0,0 +1,50 @@
|
||||
AniNIX::Forge3 will be a successor to [[Forge2|AniNIX::Forge2]] and [[Infrastructure|AniNIX::Infrastructure]]. [[AniNIX::Core]] will be turned into hardware rather than VM, and a new systemd+qemu [[ShadowArch]] install will take the role of [[Hypervisor]] from [[Windows]]. Options being evaluated are below.
|
||||
|
||||
**This is not yet live.**
|
||||
|
||||
# New Rack Layout
|
||||
* Forge2 bottom shelf, relegated to Windows [[Games]] and typically powered off.
|
||||
* Requires 27.2 x 9.9 x 25.5 inchs
|
||||
* Middle shelf: 2 PSU's in lateral
|
||||
* Next shelf: soundproof-wrapped 2 x [https://unixsurplus.com/collections/supermicro-servers/products/supermicro-1u-x8dtu-f-dual-intel-xeon-e5645-hex-core-2-4ghz-1u-server?variant=23868756487 SuperMicro X8DTU-F servers] -- one as [[Core]] and one as [[Hypervisor]]/Dev.
|
||||
* Requires 32" x 19" x 4"
|
||||
* Hypervisor will virtualize [[Darknet]], [[Sharingan]], [[Aether]], [[Maat]], [[Cerberus]], and [[DedSec]] VM's.
|
||||
* Top shelf:
|
||||
* [[Shadowfeed]]
|
||||
* [[Geth/Nazara]]
|
||||
* [[Print]]
|
||||
* Dev switch
|
||||
|
||||
## Network
|
||||
WAN link runs from modem to Shadowfeed WAN. Shadowfeed LAN are
|
||||
1. Nazara
|
||||
1. PRD ether
|
||||
1. PRD IPMI
|
||||
1. Switch WAN
|
||||
|
||||
Switch LAN are
|
||||
1. Dev ether
|
||||
1. Dev IPMI
|
||||
1. Dev table ether
|
||||
1. Windows
|
||||
|
||||
## USB
|
||||
Each PSU has a USB that should be able to connect to Nazara. This will allow Nazara to monitor active power state into Nagios.
|
||||
|
||||
## Power
|
||||
UPS 1 sockets are provided from one wall outlet, max load 1200W and average load 300W.
|
||||
1. HA
|
||||
1. PRD PSU (500W)
|
||||
1. Dev PSU (500W)
|
||||
1. Surge only
|
||||
1. Dev table strip
|
||||
1. Laptop charger (100W)
|
||||
|
||||
UPS 2 sockets are provided from a second wall outlet, max load 1300W and average load 100W, on a 25' 12-gauge outdoor extension cable.
|
||||
1. HA
|
||||
1. Shadowfeed
|
||||
1. Nazara
|
||||
1. Switch
|
||||
1. Desk light (typically off)
|
||||
1. Non-HA
|
||||
1. Windows (1200W)
|
52
Entities/Games.md
Normal file
52
Entities/Games.md
Normal file
@ -0,0 +1,52 @@
|
||||
The Games are a list of PC or emulated games available for users to play.
|
||||
|
||||
# Etymology
|
||||
Let's not play games -- this service is self-named.
|
||||
|
||||
# Relevant Files and Software
|
||||
<!-- This could be expanded. -->[[Category:TODO]]
|
||||
## AAA Titles
|
||||
* The [https://assassinscreed.wikia.com/ Assassin's Creed] series
|
||||
* Dishonored
|
||||
* Deus Ex: Human Revolution
|
||||
## Indie games
|
||||
* Hacknet_
|
||||
## MMO's
|
||||
* [http://swtor.com/ Star Wars: The Old Republic] -- AniNIX members are presently playing for the Empire faction and working with the [http://mandocabure.proboards.com/ Mando Cabure] guild. Ping an admin on IRC or Discord to join the gaming.
|
||||
<pre># This game can be installed on ShadowArch with the following:
|
||||
pacman -S wine-staging wine-mono
|
||||
winecfg
|
||||
winetricks d3dx9 vcrun2008 msls31 winhttp
|
||||
1. Download launcher from swtor.com
|
||||
wine ./SWTOR_launcher.exe
|
||||
timeout 60 wine ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.exe
|
||||
vim ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.settings
|
||||
1. Change bitraider_disable to true and download mode to SSN.
|
||||
wine ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.exe
|
||||
</pre>
|
||||
|
||||
* [http://www.crypticstudios.com/startrek Star Trek Online]
|
||||
## Independent Games
|
||||
: These are excellent for a [[Games/Team-building_Exercise|team-building exercise]].
|
||||
* [http://artemis.eochu.net Artemis Bridge Simulator]
|
||||
* [https://unvanquished.net Unvanquished]
|
||||
## Emulators
|
||||
* Desmune
|
||||
* VisualBoy Advance
|
||||
* ScummVM
|
||||
|
||||
# Available Clients
|
||||
We are investigating NVidia SHIELD technology for the AAA titles.
|
||||
|
||||
The [[Games#Independent Titles|independent titles]] have game clients that can be downloaded and the AniNIX made to be the hosting server.
|
||||
|
||||
# Additional Reference
|
||||
## Recovery
|
||||
Recovering games used to be a tired process of maintaining product keys. Today, this is less an impact. Instead, one should buy games through services that allow reinstallation of the same. [https://steampowered.com Steam] and [https://uplay.ubi.com/ Uplay] both support this functionality. SWTOR and MMO's like it do not install unique content directly to the local machine, so they are easily reinstalled.
|
||||
|
||||
Independent games or freeware should be preserved through keeping copies of the installers.
|
||||
|
||||
## Streaming
|
||||
Linux [[Tachikoma]] or [[DedSec]] hosts can stream from a Games install using Steam in-home streaming. Wireless AC connections are recommended, and [https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711 firewall rules] need to be made.
|
||||
}}
|
||||
[[Category:Internal_Service]]
|
24
Entities/Geth_Armature.md
Normal file
24
Entities/Geth_Armature.md
Normal file
@ -0,0 +1,24 @@
|
||||
The Geth Armature is a robotic body that allows the Geth to interact with the real world.
|
||||
|
||||
# Uses
|
||||
1. Physical patrolling
|
||||
1. Lock inspection
|
||||
1. Invalid care, for those unable to move on their own.
|
||||
1. Hardware inspection, in the case of an [[Sharingan|AniNIX::Sharingan]] alert.
|
||||
1. Potentially firing off other Geth-controlled units, such as carrying an IR module into range of a Roomba.
|
||||
|
||||
# Hardware
|
||||
We're coding for [http://www.swiftstreamrc.com/product/robo-buddy/ RoboBuddy from SwiftStream], but the process to be documented will be very similar for any mobile IP camera. Key requirements:
|
||||
* Articulation on the camera
|
||||
* Onboard lights
|
||||
* Durability of frame
|
||||
* Self-recharging
|
||||
* Good resolution
|
||||
|
||||
# Softare
|
||||
In development! [[Category:TODO]]
|
||||
|
||||
# Etymology
|
||||
While many Geth mobile units were modeled after their Quarian creators, larger security units were more utilitarian. The collapsible, giraffe-like Armature were the heavy armor that could be deployed into hostile territory to protect their holdings. Similarly, ours protects our locations.
|
||||
|
||||
[[Category:Entity]]
|
82
Entities/Holocron.md
Normal file
82
Entities/Holocron.md
Normal file
@ -0,0 +1,82 @@
|
||||
<b>WARNING: Holocrons should not hold copies of sensitive information.</b><br />
|
||||
The Holocron is a mobile USB designed to take over any computer hardware and run as an element of the AniNIX.
|
||||
|
||||
# Etymology
|
||||
Named for the [http://starwars.wikia.com/wiki/Holocron_of_Heresies Sith Holocron] from the Star Wars universe, the Holocron is a method for AniNIX admins to craft and record all their personal code and knowledge, including [[Aether|AniNIX::Aether]] backups, [[Foundation|Git]] repo checkouts, etc. It should be secured and difficult to crack to protect the secrets within, just as its namesake -- the better the traps, the better the knowledge it can hold.
|
||||
|
||||
# Capacity and Components
|
||||
Holocrons have no defined capacity since they are not bound to any set of hardware. The portable storage space is bound to the drive on which it's written.
|
||||
|
||||
# Hosted Services and Entities
|
||||
No services or entities are hosted.
|
||||
|
||||
# Connections
|
||||
Holocron can dial to any host desired. It should have VPN, SSH, remote-desktop, browser, code version control, and file transfer clients available.
|
||||
|
||||
# Additional Reference
|
||||
Implementation details for Holocron are below.
|
||||
|
||||
## Host drive
|
||||
We currently recommend a [https://www.pcnation.com/web/details/ZY1268/Corsair-Flash-Survivor-Stealth-64GB-USB-3-0-Flash-Drive-CMFSS3B-64GB-00843591066389?mkwid=s_dc&pcrid=64230955823&pkw=&pmt=&plc=&gclid=Cj0KEQjwo_y4BRD0nMnfoqqnxtEBEiQAWdA124R1SSj-sqFREK5wSAXJca5AVpUXJuKfbi3IuD_Sn2IaArOC8P8HAQ Corsair Survivor Stealth] for Holocrons. This offers 64GB of flash storage with the following layout, in a form that is both impact- and water-resistant, making it a resilient tool.[[Category:Corsair]]
|
||||
|
||||
<pre>
|
||||
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
||||
fd0 2:0 1 4K 0 disk
|
||||
sda 8:0 0 1G 0 disk
|
||||
sdb 8:16 1 59.6G 0 disk
|
||||
|-sdb1 8:17 1 40G 0 part /mnt/xplatfrm
|
||||
|-sdb2 8:18 1 9.3G 0 part /boot
|
||||
`-sdb3 8:19 1 9.3G 0 part
|
||||
`-spartacus 254:0 0 9.3G 0 crypt /
|
||||
sr0 11:0 1 544K 0 rom
|
||||
</pre>
|
||||
|
||||
<b>WARNING: Do not store sensitive information on Holocrons!</b><br/> Though a Holocron has its root encrypted, /boot is not and the device is portable. Physical access is death! The storage can be cloned and cracked with sufficient computing resources. The encryption is a delay but not a hard-stop protecting your information. If you have access to an encrypted machine like [[Core|AniNIX::Core]] there is no reason to keep sensitive information on this, a client device. If you have nothing else, this encryption is better than none.
|
||||
|
||||
The Israelis and such have been working out ways to listen with directional mics to crack encryption, and I have no guarantee they didn't use some similar hardware assault to crack the encryption. The algorithm might be smart enough, but the hardware may give rise to a more direct way. Moreover, with the hardware being mobile, the firmware and bootloader could be assaulted to broadcast key signatures from memory, or someone could record you entering the decryption password. Some example vectors are below:
|
||||
* [http://www.tau.ac.il/~tromer/acoustic/ Accoustic attacks on RSA]
|
||||
* [https://dx.eng.uiowa.edu/dave/lukstext.php A sample LUKS crack]
|
||||
* [http://www.prnewswire.com/news-releases/passware-first-to-enable-computer-forensics-to-crack-linux-disk-encryption-luks-300004871.html Another potential LUKS crack]
|
||||
|
||||
## Installation
|
||||
1. Install [[ShadowArch]] to the / partition. Remember to remove the first four lines so that your mount options are used with your storage layout.
|
||||
1. Create a folder /boot/iso in the / partition.
|
||||
1. Edit /etc/grub.d/40_custom:
|
||||
1. See [https://wiki.archlinux.org/index.php/Multiboot_USB_drive Arch's multiboot] for individual GRUB entries.
|
||||
1. Also see [https://releng.archlinux.org/pxeboot/ Arch's netboot] for a GRUB entry to use for netboot.
|
||||
1. Load ISOs and pack for travel.
|
||||
|
||||
|
||||
Example 40_custom file:
|
||||
<pre>
|
||||
1. !/bin/bash
|
||||
exec tail -n +3 $0
|
||||
probe -u $root --set=rootuuid
|
||||
set imgdevpath="/dev/disk/by-uuid/$rootuuid"
|
||||
menuentry 'ArchLinux ISO' {
|
||||
set isofile='/iso/archlinux.iso'
|
||||
loopback loop $isofile
|
||||
linux (loop)/arch/boot/x86_64/vmlinuz archisodevice=/dev/loop0 img_dev=$imgdevpath img_loop=$isofile earlymodules=loop
|
||||
initrd (loop)/arch/boot/x86_64/archiso.img
|
||||
}
|
||||
menuentry "Kali Linux ISO" {
|
||||
set isofile='/iso/kali-linux.iso'
|
||||
loopback loop $isofile
|
||||
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali earlymodules=loop
|
||||
initrd (loop)/live/initrd.img
|
||||
}
|
||||
menuentry "CentOS ISO" {
|
||||
set isofile='/boot/iso/CentOS.iso'
|
||||
loopback loop $isofile
|
||||
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:/dev/sdb2:/$isofile
|
||||
initrd (loop)/isolinux/initrd.img
|
||||
}
|
||||
</pre>
|
||||
|
||||
## Recommended uses
|
||||
* ArchLinux ISO: This ISO can be used to have a clean point from which to start -- its signature and size can be compared against [https://archlinux.org/download the ArchLinux page] for integrity.
|
||||
* Kali Linux ISO: This ISO is a hack suite, porting the latest tools with the user.
|
||||
* CentOS ISO: This allows a user to access an enterprise network using a trusted OS with a known signature.
|
||||
* ArchLinux local install: This is a portable workspace for the carrier -- packages installed here will be persistent, and allow the user to boot their own toolset without any or much network traffic.
|
||||
* Cross-platform storage: This allows Spartacus to perform as a usual flash-drive.
|
||||
}}
|
26
Entities/Infrastructure.md
Normal file
26
Entities/Infrastructure.md
Normal file
@ -0,0 +1,26 @@
|
||||
The Infrastructure is a conglomerate of machines with mostly proprietary firmware providing power and connectivity to the AniNIX.
|
||||
|
||||
# Etymology
|
||||
This should be self-explanatory -- the Infrastructure describes the lowest-level connection between the digital world of the AniNIX and the physical world. The Infrastructure passes raw resources from the physical world for the AniNIX to manipulate.
|
||||
|
||||
# Capacity and Components
|
||||
The capacity of the Infrastructure is limited by the following areas:
|
||||
* Power: 1500VA / 900W with surge protection on all sockets and battery power on three sockets for roughly 20 minutes of operation under the usual AniNIX load. [[Category:HasBattery]] Power is provided by Madison Gas & Electric [[Category:MG&E]] via a CyberPower UPS [[Category:CyberPower]]
|
||||
* Network: Charter Communications modem providing, ostensibly, a 500MB/s upload and 6Gb/s download speed. SpeedTest.com results fluctuate. [[Category:Charter]]
|
||||
|
||||
# Hosted Services and Entities
|
||||
{{Reference|Shadowfeed}}{{Reference|Forge2}}
|
||||
|
||||
# Connections
|
||||
{{Reference|Windows}}
|
||||
|
||||
# Additional Reference
|
||||
For hosts seeking insight into the Infrastructure, they can install the PowerPanel software from CyberPower. ArchLinux contains a copy of it in the AUR: [https://aur.archlinux.org/packages/powerpanel/ linked here]
|
||||
|
||||
The following files are then critical for configuration, after the USB device is connected to the monitoring host:
|
||||
* /etc/pwrstatd.conf
|
||||
* /etc/powerpanel/pwrstatd-email.sh
|
||||
* /etc/powerpanel/pwrstatd-lowbatt.sh
|
||||
* /etc/powerpanel/pwrstatd-powerfail.sh
|
||||
* /usr/lib/systemd/system/pwrstatd.service
|
||||
}}
|
10
Entities/Print.md
Normal file
10
Entities/Print.md
Normal file
@ -0,0 +1,10 @@
|
||||
Print is the printer/scanner of the AniNIX, aimed at offering the option to convert materials from digital to physical and vice-versa.
|
||||
|
||||
# Etymology=This entity is self-named.
|
||||
|
||||
# Capacity and Components=A [[Category:Brother]]Brother MFC-J430W will fill this role nicely, with color printing, scanning, and (unused) faxing abilities. It can be easily installed from [https://aninix.net/foundation/ConfigPackages/ ConfigPackages].
|
||||
|
||||
# Hosted Services and Entities=There are no hosted aspects.
|
||||
|
||||
# Connections={{Reference|Core}}
|
||||
}}
|
1
Entities/Roomba.md
Normal file
1
Entities/Roomba.md
Normal file
@ -0,0 +1 @@
|
||||
[[Category:TODO]]Roomba is a cleaning bot for the AniNIX
|
42
Entities/Rufus.md
Normal file
42
Entities/Rufus.md
Normal file
@ -0,0 +1,42 @@
|
||||
Rufus is an overlay to make use of unused clock cycles on AniNIX hardware. It allows the AniNIX to take what would otherwise be wasted power and network presence and put it to either profit or charity.
|
||||
|
||||
# Etymology=Rufus is named after the naked mole rat from the Kim Possible TV series; a ubiquitious companion to the protagonists, Rufus' species is also capable of great feats of digging, given their traditionally subterranean habitat. The Rufus system is equally useful at mining resources for the AniNIX, keeping it online.
|
||||
|
||||
# Capacity and Components=Capacity depends on the number of rigs available. A "rig" may simply be a [[Geth/Hub|AniNIX::Geth hub]], a running VM, or a full-featured rig.
|
||||
|
||||
Our full-featured rigs are built from cheap consumer-grade parts.<ref name=motherboard>[https://www.youtube.com/watch?v=3YMxGGXme8g Motherboard Ethereum mining presentation], accessed 2/5/18]</ref>. We have a list of our current desired parts at [https://secure.newegg.com/Wishlist/SharedWishlistDetail?ID=vcB3403ONPRZhXHgzQNC%2fg%3d%3d Newegg].
|
||||
|
||||
# Hosted Services and Entities
|
||||
## Ethereum
|
||||
[https://ethereum.org Ethereum]<ref name=eth>https://wiki.archlinux.org/index.php/Ethereum</ref> is a decentralized currency and contract blockchain.
|
||||
|
||||
Install and upgrade python3. From that, we can install [http://raspnode.com/diyEthereumPyeth.html PyEthApp] to mine the currency.
|
||||
<pre>
|
||||
pip3 install pyethapp
|
||||
</pre>
|
||||
|
||||
Multiple miners can be supported in a single network, but port 30303 must be forwarded to the first node. Other nodes in the cluster will connect their ethminer to that node.
|
||||
|
||||
Funds can be transferred to an Ethereum wallet by TODO.[[Category:TODO]][[Category:Coinbase]]
|
||||
|
||||
## Bitcoin
|
||||
Bitcoin<ref name=btc>https://wiki.archlinux.org/index.php/Bitcoin</ref> is another decentralized blockchain currency -- in fact, it was the first and most popular.
|
||||
|
||||
Mining is done by connecting GPU's or [https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=Raspberry+pi+ASIC+bitcoin ASIC miners] to your host. From there, install bfgminer and benchmark the attached ASIC's. This can be done by standalone block mining or pool mining, where a group of miners agree to mine for the same block through shared and decentralized work.
|
||||
|
||||
When satisfied with the operation of the benchmarking, bfgminer can be run with all hardware and a Coinbase address to receive the funds.
|
||||
|
||||
## Folding@Home
|
||||
[https://foldingathome.org/ Folding@Home]<ref name=fah>https://wiki.archlinux.org/index.php/Folding@home</ref> is a Stanford project for protein folding research, helping researchers solve disease problems. This is our premiere project for our [https://aninix.net/pages/charity.php charity work].
|
||||
|
||||
Install the [https://aur.archlinux.org/packages/foldingathome/ Folding@Home package] from Stanford. This will allow you to receive units of work from Stanford and process them.
|
||||
|
||||
## BOINC
|
||||
[http://boinc.berkeley.edu/ BOINC] is a Berkley project for supporting underfunded research projects by allowing open computing resources.
|
||||
|
||||
Install the [https://www.archlinux.org/packages/?name=boinc-nox boinc-nox]<ref name=boinc>https://wiki.archlinux.org/index.php/BOINC</ref> package from Berkley. Enabling the service will use your compute resources for the needy projects.
|
||||
|
||||
# Connections=Rufus runs on any available hardware.
|
||||
|
||||
# Additional Reference=[https://aninix.net/irc/ Contact an admin] for current ROI -- example math can be seen in [https://www.youtube.com/watch?v=8eXI_7O4Svc this presentation]. Also, [https://www.youtube.com/watch?v=U_LK0t_qaPo this presentation] offers an overview of how Ethereum the protocol works.}}
|
||||
# References
|
51
Entities/Shadowfeed.md
Normal file
51
Entities/Shadowfeed.md
Normal file
@ -0,0 +1,51 @@
|
||||
The Shadowfeed is the networking gateway between the AniNIX and the outside world -- it broadcasts the AniNIX signal and allows the network to communicate.
|
||||
|
||||
# Etymology
|
||||
The Shadowfeed is named after a resistance communications network in the Star Wars universe. The [http://starwars.wikia.com/wiki/CIS_Shadowfeed Shadowfeed] was a disseminated network routed through existing communications technology, allowing a separatist movement to broadcast its message.
|
||||
|
||||
# Capacity and Components
|
||||
The Shadowfeed is an Netgear R7000 Nighthawk router hardware flashed with DD-WRT firmware.[[Category:DD-WRT]][[Category:Netgear]] It can hold numerous clients wirelessly, and it supports wired USB 2.0 and 3.0 hard-drives to create simple NAS storage. There are five physical slots, one occupied by wired connection to the Forge2 frame, one by a connection to the Verizon wireless tower, and one to the Infrastructure. One remaining slot is free with a 100ft Cat5e cable and the other reserved for hotswap in case of port failure or LAN need.
|
||||
|
||||
<b>Note:</b> the best place we've found to grab firmware updates is [https://ddwrt-kong.clonevince.fr/ this upload site for Kong's builds]. Ensure that you are on build 33525 or later to avoid being vulnerable to [https://aircrack-ng.blogspot.com/2017/10/krack-wpa-vulnerability-key.html KRACK]. Follow the instructions [https://dd-wrt.com/wiki/index.php/Installation from the DD-WRT Wiki] to flash your router with new firmware or to patch. Make sure to watch for the peacocking notes! Use the dork "kong dd-wrt build <buildnumber>" -- if you use Chromecasts for [[Geth|AniNIX::Geth]], make sure to look for explicit validation of the devices, or run your own extensive regressions.
|
||||
|
||||
# Hosted Services and Entities
|
||||
Nothing is hosted by the Shadowfeed, but it is manageable by either SSH or an onboard webserver.[[Category:Lighttpd]]
|
||||
|
||||
# Connections
|
||||
The Shadowfeed has a number of hosts and entities that connect to it -- unknown entities are routed to a guest network, while known hosts are allowed inside the DMZ where they can access internal services. Direct AniNIX network members are listed below.
|
||||
{{Reference|Core}}{{Reference|Windows}}{{Reference|DarkNet}}{{Reference|Print}}{{Reference|Bastion}}{{Reference|Tricorder}}{{Reference|Geth}}{{Reference|Forge2}}{{Reference|Infrastructure}}
|
||||
|
||||
# Additional Reference
|
||||
## Add NAT Rule
|
||||
<pre>
|
||||
iptables -t nat -I PREROUTING -p tcp -d $(nvram get wan_ipaddr) --dport 3389 -j DNAT --to 10.0.1.2 [ -s SourceIP ]
|
||||
iptables -I FORWARD -p tcp -d 10.0.1.2 --dport 3389 -j ACCEPT
|
||||
iptables -t nat -I PREROUTING -p udp -d $(nvram get wan_ipaddr) --dport 3389 -j DNAT --to 10.0.1.2 [ -s SourceIP ]
|
||||
iptables -I FORWARD -p udp -d 10.0.1.2 --dport 3389 -j ACCEPT
|
||||
</pre>
|
||||
## Direct config alteration
|
||||
nvram show will get all the current options, whereas nvram get variable will return a variable.
|
||||
|
||||
nvram set or unset change variables.
|
||||
|
||||
nvram commit pushes the change.
|
||||
|
||||
## Guest Wifi
|
||||
[https://dd-wrt.com/wiki/index.php/Guest_Network See here.]
|
||||
|
||||
## Sample Startup Script
|
||||
The following will insert firewall lines into your sample startup script to harden your network edge. This allows [[WebServer|web]], [[SSH]], [[IRC]], [[Geth|AniNIX::Geth]], and [[Nazara|bastion]] access through the firewall, dropping all others. It also sets up the block chain for [[Cerberus|AniNIX::Cerberus]].
|
||||
|
||||
<pre>
|
||||
iptables -N severe
|
||||
iptables -I INPUT 2 -i vlan2 -j DROP
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 22 -j ACCEPT
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 80 -j ACCEPT
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 443 -j ACCEPT
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 6641 -j ACCEPT
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 6697 -j ACCEPT
|
||||
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 9022 -j ACCEPT
|
||||
iptables -I INPUT 2 -j severe
|
||||
iptables -I FORWARD -j severe
|
||||
</pre>
|
||||
}}
|
10
Entities/Tachikoma.md
Normal file
10
Entities/Tachikoma.md
Normal file
@ -0,0 +1,10 @@
|
||||
|Tachikoma|Tachikoma are individual user or service machines.|
|
||||
word
|
||||
These are named after [https://www.youtube.com/watch?v=lNY53tZ2geg Tachikoma from Ghost in the Shell]. These AI-powered tanks offered personal transportation, concealment,
|
||||
|
||||
# Capacity and Components
|
||||
Capacity is indeterminate -- depends on the hardware being used.
|
||||
|
||||
# Hosted Services and Entities=No services should be hosted for Tachikoma, despite [[SSH|an SSH server for remote access]].
|
||||
|
||||
# Connections=Varies by purpose}}
|
48
Entities/Tricorder.md
Normal file
48
Entities/Tricorder.md
Normal file
@ -0,0 +1,48 @@
|
||||
Omnitool is a mobile smartphone client of the network.
|
||||
|
||||
# Etymology
|
||||
The Tricorder is named after the fictional and ubiquitous devices from the Star Trek universe. Because the Tricorder is useful in a number of situations, hand-held in the same way, and is almost always handled by an Admin save during sleep, the name was apt.
|
||||
|
||||
Besides, we like the subtlety, craftiness, and paranoia of the Romulans.
|
||||
|
||||
# Capacity and Components
|
||||
This is a Verizon Wireless Droid Turbo smartphone running the Android OS. [[Category:USCellular]][[Category:Google]]
|
||||
* 48 hours of usability
|
||||
* 5.2" Gorilla Glass 4 Display with 1920x1080 resolution
|
||||
* 32 GB of onboard storage, encrypted with Android PIN
|
||||
* Microphone
|
||||
* 16MP Camera
|
||||
* CDMA, GSM, WCDMA, UMTS, LTE Network-capable with US Cellular SIM
|
||||
|
||||
# Hosted Services and Entities
|
||||
The Tricorder can host a couple remote-management tools.
|
||||
* Apps can be remotely installed with [https://play.google.com/ Google Play Store].
|
||||
* Location identification, remote locking, and remote wiping can be achieved with [https://google.com/android/devicemanager Google Device Manager].
|
||||
* SMS, notifications, and call response can be remotely controlled with a vivoactive HR or [https://aninix.net/wiki/Subscriptions#Pushbullet Pushbullet].
|
||||
|
||||
# Connections
|
||||
This device has clients for the following entities.
|
||||
{{Reference|Singularity}}{{Reference|Yggdrasil}}{{Reference|Eyes}}{{Reference|SSH}}
|
||||
This device physically can connect to the following.
|
||||
{{Reference|Infrastructure}}{{Reference|Shadowfeed}}{{Reference|Forge2}}
|
||||
This device can also extend Bluetooth and WiFi technology to the following devices, to extend the AniNIX's reach.
|
||||
* Drones, such as the Parrot AR.Drone 2.0, over WiFi
|
||||
* Smart devices, like the Garmin vivoactive HR smartwatch or smart scales, over bluetooth
|
||||
* Car and other stereos over Bluetooth (this is particularly useful for playing back audio from Yggdrasil)
|
||||
* Bluetooth-capable devices for file transfer
|
||||
* WiFi-capable devices via ad-hoc WiFi network
|
||||
|
||||
# Additional Reference
|
||||
* [https://www.lg.com/us/cell-phones/lg-US701-Black-us-cellular Reference page]
|
||||
* [https://memory-alpha.wikia.com/wiki/Romulan_tricorder Star Trek Wiki page]
|
||||
## Recovery Path
|
||||
Please encrypt your Tricorder for privacy reasons. For those concerned, here is your recovery path, should the device be rendered inoperable or inaccessible.
|
||||
* The Google Play Store records all applications installed on the phone.
|
||||
* Music, pictures, and video should be replicated from [[Yggdrasil|AniNIX::Yggdrasil]]. Please use an [[SSH|SFTP]] client to regularly store your necessary files on your AniNIX account, or upload your files to a trusted storage service. For insecure files, [https://drive.google.com Google Drive] is sufficient and free.
|
||||
* Customizations will be lost but should be easily recreated.
|
||||
* SSH Keys should be recreated. Remove any existing public keys from servers the device had access to.
|
||||
* Android devices can be remotely wiped, locked, or pinged from Android Device Manager.
|
||||
|
||||
Most severe problems with an Android device can be fixed with a factory reset, patching, app re-installation from the Play Store, and pulling down any desired files. While this is a cumbersome process, for non-rooted, encrypted devices, this is often the easiest route.
|
||||
}}
|
||||
{{Mobile}}
|
49
Entities/Windows.md
Normal file
49
Entities/Windows.md
Normal file
@ -0,0 +1,49 @@
|
||||
: <b>Warning: Windows may reformat non-Windows partitions with no warning during boot. We recommend keeping strong backups and controlling when Windows Update runs. See [http://www.omgubuntu.co.uk/2016/08/windows-10-anniversary-update-delete-partition OMGUbuntu's article] for end user experiences.</b>
|
||||
Windows is a ubiquitous desktop environment for home computing, still compromising the majority of the market. The AniNIX hosts a virtualized Windows host to access the tools and software developed for that OS.
|
||||
|
||||
# Etymology
|
||||
The Windows host is named for the OS it runs.
|
||||
|
||||
# Capacity and Components
|
||||
Windows' components are provided by Microsoft. [[Category:Microsoft]] The Windows host is granted networking, USB assignments, the GTX 760 pair, 2TB of storage, 8 GB RAM, and 4 cores from [[Forge2]].
|
||||
|
||||
# Hosted Services and Entities
|
||||
{{Reference|Games}}{{Reference|VirusScan}}
|
||||
## Customization
|
||||
There is a desktop theme available to skin the Windows desktop environment in the same fashion as [[ShadowArch]], the WebServer and the Wiki. Download it from [https://aninix.net/aninix.deskthemepack this link].
|
||||
## Standard Packages
|
||||
Available from [https://aninix.net/wolfpack WolfPack's repo]:
|
||||
* SeaMonkey Browser
|
||||
* Chrome Browser can be used in place of SeaMonkey or in addition to support Chromecasts.
|
||||
* PuTTY Terminal Emulator
|
||||
* WinSCP File Transfer
|
||||
* Launchy to emulate Linux Alt+F2 running
|
||||
* VNC viewer
|
||||
* Xming X11 server
|
||||
* DaemonTools Lite for mounting ISO's.
|
||||
|
||||
## Hypervisor Role
|
||||
A Hypervisor should also be deployed.
|
||||
* A Windows 10 Pro license offers Hyper-V, which allows enterprise-style VM availability
|
||||
* VMWare Workstation or VirtualBox are also alternatives.
|
||||
|
||||
## Work Role Packages
|
||||
* WebEx
|
||||
* AnyConnect
|
||||
* One productivity suite from:
|
||||
* LibreOffice
|
||||
* Microsoft Office
|
||||
* Notepad++
|
||||
|
||||
# Connections
|
||||
{{Reference|Forge2}}{{Reference|Shadowfeed}}{{Reference|Infrastructure}}
|
||||
|
||||
# Additional Reference
|
||||
Remember the following things when dealing with Windows:
|
||||
* Windows updates and upgrades stand a very good chance of being destructive to other systems and itself. Never upgrade without a backup, and everything installed on Windows should have an independent recovery plan. See [[Games#Recovery]] for an example.
|
||||
* Windows tries to send data to Microsoft. Check account settings to opt out.
|
||||
* Always disable autorun to help slow malware.
|
||||
|
||||
## Unified Credentials
|
||||
Install [https://pgina.org/ pGina] for LDAP authentication, including with [[Sora|AniNIX::Sora]].[[Category:LDAP]]
|
||||
}}
|
31
LICENSE
Normal file
31
LICENSE
Normal file
@ -0,0 +1,31 @@
|
||||
# http://www.wtfpl.net/about/
|
||||
|
||||
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
|
||||
Version 2, December 2004
|
||||
|
||||
Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim or modified
|
||||
copies of this license document, and changing it is allowed as long
|
||||
as the name is changed.
|
||||
|
||||
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. You just DO WHAT THE FUCK YOU WANT TO.
|
||||
|
||||
ANINIX ADDENDUM
|
||||
|
||||
Trademark 2017 (https://aninix.net/)
|
||||
|
||||
The "AniNIX" name and |> logo are trademarked as of 2017/11/21.
|
||||
AniNIX materials may be reproduced and re-used (though you must
|
||||
contact the admins of the network to get written permission to use
|
||||
the AniNIX name or logo) so long as such reproduction or re-use
|
||||
does not inhibit the original AniNIX use of the same.
|
||||
|
||||
Attribution is appreciated for other materials but not legally
|
||||
required or necessary.
|
||||
|
||||
"AniNIX" trademark serial: 87177883
|
||||
|> Logo trademark serial: 87177887
|
68
Layouts/Security_Layout.md
Normal file
68
Layouts/Security_Layout.md
Normal file
@ -0,0 +1,68 @@
|
||||
This offers a detail of the security hierarchy of the AniNIX, which is layered in the following sections.
|
||||
|
||||
# Physical security
|
||||
Physical security includes storing the [[Forge2]] in a locked second-floor building. [[Cerberus]] offers reporting on events in this location. Admins co-locate with this location and are trained in combat and close quarters defense. Physical intrusions will be rebuffed to the fullest extent of the law.
|
||||
|
||||
# Network/Software protection
|
||||
{{Organizer|Firewall|
|
||||
{{Organizer|Shadowfeed|
|
||||
{{Organizer|Trusted DMZ|
|
||||
{{Reference|DarkNet}}
|
||||
{{Organizer|Core|
|
||||
{{Organizer|Cerberus|
|
||||
{{Organizer|Firewall|
|
||||
Most of the services in the AniNIX are monitored by network-level intrusion detection
|
||||
## Open-access Services
|
||||
{{Reference|WebServer}}{{Reference|TheRaven}}{{Reference|Foundation}}{{Reference|Heartbeat}}
|
||||
## Password-Restricted Services
|
||||
{{Reference|IRC}}{{Reference|Wiki}}{{Reference|Yggdrasil}}
|
||||
## Remote Access
|
||||
{{Organizer|Cerberus|
|
||||
The SSH service supports password and key authentication.
|
||||
{{Reference|SSH}}
|
||||
|Cerberus}}
|
||||
}}
|
||||
|Cerberus}}
|
||||
|Core}}
|
||||
{{Organizer|Windows|
|
||||
{{Organizer|Firewall|
|
||||
{{Reference|Games}}
|
||||
}}
|
||||
|Windows}}
|
||||
}}
|
||||
{{Organizer|Guest DMZ|
|
||||
Any visitors to the AniNIX premises are given access to the outside Internet via the Shadowfeed, but this access is isolated away from AniNIX systems.
|
||||
}}
|
||||
|Shadowfeed}}
|
||||
}}
|
||||
|
||||
# Filesystem security
|
||||
{{Organizer|Forge2|
|
||||
{{Organizer|Cerberus|
|
||||
{{Organizer|VirusScan|
|
||||
The Hypervisor content lives here.
|
||||
|VirusScan}}
|
||||
|Cerberus}}
|
||||
{{Organizer|Core|
|
||||
{{Organizer|LUKS-on-LVM Volume|
|
||||
{{Organizer|Cerberus|
|
||||
{{Organizer|VirusScan|
|
||||
Most of the data lives inside these layers.
|
||||
|VirusScan}}
|
||||
|Cerberus}}
|
||||
}}
|
||||
|Core}}
|
||||
{{Organizer|Windows|
|
||||
{{Organizer|VirusScan|
|
||||
The Windows data lives here.
|
||||
|VirusScan}}
|
||||
|Windows}}
|
||||
|Forge2}}
|
||||
|
||||
# Backups
|
||||
[[Windows]] and [[Core]] are backed up locally on mirrored, non-RAID disks. They are also backed up to a 4TB hard drive from the [[Forge2]] to an off site safety deposit box in a bank, making it very difficult to destroy all copies of these hosts.
|
||||
|
||||
Should all backups be lost, the [[Aether]] project also backs up Core's critical configuration files and a list of files in [[Yggdrasil]] to an anonymous list of servers. [[Grimoire]]'s databases are independently archived to a password-based tarball and stored in cloud storage.
|
||||
|
||||
[[Category:Security]]
|
||||
[[Category:Layout]]
|
19
Layouts/Service_and_Host_Layout.md
Normal file
19
Layouts/Service_and_Host_Layout.md
Normal file
@ -0,0 +1,19 @@
|
||||
{{Reference|Holocron}}
|
||||
{{Organizer|Infrastructure|
|
||||
{{Organizer|Shadowfeed|
|
||||
{{Reference|Tricorder}}{{Reference|Geth}}{{Reference|Bastion}}{{Reference|Print}}{{Reference|TeamRed}}{{Reference|TeamGreen}}{{Reference|TeamBlue}}
|
||||
{{Organizer|Forge2|
|
||||
{{Organizer|Windows|
|
||||
{{Reference|Games}}
|
||||
|Windows}}
|
||||
{{Organizer|Core|
|
||||
{{Reference|Aether}}{{Reference|Cerberus}}{{Reference|Foundation}}{{Reference|Geth}}{{Reference|Grimoire}}{{Reference|Heartbeat}}{{Reference|IRC}}{{Reference|TheRaven}}{{Reference|Singularity}}{{Reference|Sora}}{{Reference|SSH}}{{Reference|WebServer}}{{Reference|Wiki}}{{Reference|WolfPack}}{{Reference|VirusScan}}{{Reference|Yggdrasil}}
|
||||
|Core}}
|
||||
{{Organizer|DarkNet|
|
||||
{{Reference|VirusScan}}{{Reference|WolfPack}}
|
||||
|DarkNet}}
|
||||
|Forge2}}
|
||||
|Shadowfeed}}
|
||||
|Infrastructure}}
|
||||
|
||||
[[Category:Layout]]
|
86
Operation/AniNIX::Wiki:Manual_of_Style.md
Normal file
86
Operation/AniNIX::Wiki:Manual_of_Style.md
Normal file
@ -0,0 +1,86 @@
|
||||
This is intended to give contributors a baseline for editing.
|
||||
|
||||
# Proper naming
|
||||
Services on this network are properly titled in the below format. This should always be used the first time a service is referenced.
|
||||
<pre>AniNIX::{ServiceName}[/{Area}][ \\ {Title}]</pre>
|
||||
|
||||
# Grammar
|
||||
Grammar is a writer's toolbox. You can't build good sentences without knowing how to use your tools. Since a wiki article should be as clear as possible for all those reading it, editors should keep their edits as grammatically correct as is possible, in order to ensure clear communication of the information being provided.<ref name="acwiki">[http://assassinscreed.wikia.com/wiki/Assassin's_Creed_Wiki:Manual_of_Style Assassin's Creed Wiki MoS]</ref>
|
||||
|
||||
## Capitalization
|
||||
Words should be capitalized at the start of each sentence, and when they are denoting a name or title, in line with current grammatical precedent, for example:<ref name="acwiki"/>
|
||||
|
||||
::"The Aether project should be used to back up critical servers."
|
||||
|
||||
## Titles of works
|
||||
Titles of works should be italicized to make clear that they are names; the titles of articles, chapters, and other short works should not be italicized, but are enclosed in double quotation marks.
|
||||
|
||||
# Writing Style
|
||||
:*“I believe the road to hell is paved with adverbs”* -- Stephen King
|
||||
|
||||
We now come to the meat of an article: the words themselves. When you're editing wikis, you're both academic and artist. You have to be accurate, but you also have to be interesting. Neither one can dominate; you have to skillfully balance both.<ref name="acwiki"/>
|
||||
|
||||
**Keep your writing concise.** Don't use two words where one will do. Keeping your writing simple will make it easy to understand and easy to expand on. Use complete sentences whenever possible. When you write, use grammar as a toolbox: know the rules, but only break them on purpose.<ref name="acwiki"/>
|
||||
|
||||
**Check your spelling and grammar.** Do not use 'u' in place of 'you' or '2' in place of 'to'. Write the way you would for a class paper or a newspaper article.<ref name="acwiki"/>
|
||||
|
||||
**Keep all of the topics you cover within the scope of the article.** What that means is, you don't need to give a detailed history of all AI on the page about [[TheRaven|AniNIX::TheRaven]]. Consider the article's title as your point of origin and write from that perspective. Make use of the wiki's ability to link to more detailed articles or external sources for more information.<ref name="acwiki"/>
|
||||
|
||||
**Write from an impersonal perspective.** Do not use "I." For example, do not write, "In the years that followed, Ezio began a quest to rediscover the lost history of the Order, <strike>As far as I know</strike>." Avoid drawing attention to the author (yourself) as much as possible.<ref name="acwiki"/>
|
||||
|
||||
**Be bold.** If you know something is wrong, correct it. If you think you could word something better, write it. If an article has a glaring deficiency, fill it. Even if your first attempt isn't golden, you can fix it later or someone else will come along and fix it for you. Don't be afraid to screw up.
|
||||
<ref name="acwiki"/>
|
||||
|
||||
**Use present tense.** These services, enttitles and policies are active, living, and fluid -- because they're changing now, we use present tense to describe current state.
|
||||
|
||||
# Images
|
||||
Images make an article memorable and pretty. They can speak where words fail. At the same time, misplaced or untidy images can detract from an article. When choosing images, keep in mind placement, size, and the appropriateness of the image to the section. Let images flow with the text instead of break it up.<ref name="acwiki"/>
|
||||
|
||||
Large images such as screenshots should use the "thumb" (example:<code><nowiki>[[Image:CoolImage.png|thumb]]</nowiki></code>) option which displays large images as thumbnails. Images should generally be right aligned to enhance readability by allowing a smooth flow of text down the left margin - the "thumb" option does this by default. If an infobox is not being used in an article, a right aligned picture in the lead section is encouraged.<ref name="acwiki"/>
|
||||
|
||||
Images should be kept to a minimal number -- three or fewer inline images per article. High-quality images should be stored in [[Yggdrasil|AniNIX::Yggdrasil]].
|
||||
|
||||
### Galleries
|
||||
When an article has many images, or can be improved by having more, and having inline images can detract from its readability, the use of a <code><nowiki><gallery></nowiki></code> section is encouraged. See the [[#Useful_Snippits|Useful Snippets]] for how to implement that.<ref name="acwiki"/>
|
||||
|
||||
Galleries should be five images or less. More images than that or exceptionally high-quality images should be in [[Yggdrasil]].
|
||||
|
||||
# Useful Snippets
|
||||
## Tables
|
||||
<pre>
|
||||
{|class="wikitable"
|
||||
|-
|
||||
| Cell 1 || Cell2
|
||||
|-
|
||||
|}
|
||||
</pre>
|
||||
## Transclusion
|
||||
This will include an entire other page in yours.
|
||||
<pre>{{:Wiki}}</pre>
|
||||
## Links
|
||||
Internal: <pre>[[Wiki]]</pre>
|
||||
External: <pre>[https://aninix.net/root.php WebServer]</pre>
|
||||
## Styling
|
||||
<pre>
|
||||
*Bold*
|
||||
**Italic**
|
||||
</pre>
|
||||
|
||||
## Images
|
||||
<pre>
|
||||
[[File:Image|thumb|250px|right|Some caption]]
|
||||
</pre>
|
||||
|
||||
## Gallery
|
||||
<pre>
|
||||
<gallery>
|
||||
Image:Example.jpg|Caption
|
||||
Image:Example.jpg|Caption
|
||||
</gallery>
|
||||
</pre>
|
||||
|
||||
## If/then
|
||||
<pre>{{#if:{{{add|}}}|==Additional Reference
|
||||
{{{add}}}|}}</pre>
|
||||
|
||||
[[Category:Operation]]
|
66
Operation/Archive/RCAs_2016-2018.md
Normal file
66
Operation/Archive/RCAs_2016-2018.md
Normal file
@ -0,0 +1,66 @@
|
||||
{{DowntimeRCA|Windows Update Failure|cause
|
||||
As background, [[Windows|AniNIX::Windows]] was installed originally as Windows 7 Home. It was later upgraded to Windows 10 Home and then Windows 10 Pro to add functionality for Hyper-V and Remote Desktop (though only to targeted IP's -- this service is considered a convenience and a vulnerability).
|
||||
|
||||
The AniNIX was brought down after a Windows update on 8/24/2016. The AniNIX had had other downtimes recently on calls with Microsoft as the Windows cdrom.sys driver was not recognizing drives that were ostensibly plug-and-play. Many fixes, including reordering SATA slots, registry updates, calls with drive manufacturers for drivers, adding/removing the hardware in Device Manager, etc. had been tried and not succeeded. This issue was on hold at the time of the update.
|
||||
|
||||
When Windows started again, it would only flash a "CRITICAL_PROCESS_DIED" error message. Booting with [[Holocron|AniNIX::Holocron]] showed no memory issues or other hardware problems. Using a Windows installation medium (on USB), we were not able to restore to a system restore point before the update or correct the issue with the installation. We were also not able to access the prior system images taken with the Windows backup utility.
|
||||
|
||||
Discussions with Microsoft indicate that the upgrades fro Windows 7 to Windows 10 Pro had suffered silent failures that were not logged to the user. While the operating system would limp along in functionality, it was unable to be repaired and required a reinstall.
|
||||
|length=~24 hours
|
||||
|resolution
|
||||
|
||||
At this point, the [[Forge2|AniNIX::Forge2]] frame was disconnected and all SATA lines except for the 60GB SSD were severed. Windows 10 Pro was re-installed to this disk, and display drivers were re-installed. The standard and Hypervisor packages were re-installed. [[Games]] were left to be rebuilt over time.
|
||||
|
||||
The frame was then brought down again and other drives reconnected, with the exception of the original Windows 10 drive. This drive will be left disconnected and system images abandoned short-term as a form of backup. Instead, backups will be taken of all installers used during the recovery process along with the Windows 10 Pro product key and registry.
|
||||
|commits
|
||||
}}
|
||||
|
||||
{{DowntimeRCA|Windows Virtual Disk Failure|cause
|
||||
On 9/17/2016, the [[Forge2#Hypervisor_Notes|AniNIX::Forge2]] Hypervisor logged error messages about a reset being sent to the RAID1 device, an [[Windows]] warning-level event with an id of 129 and source storahci. From then on, every five seconds, error messages were logged about disks: "An error was detected on device \Device\Harddisk1\DR1 during a paging operation." with an error ID of 51 and source of disk. Also every five seconds, NTFS error of id 140 was logged with the error message "The system failed to flush data to the transaction log. Corruption may occur in VolumeId: F:, DeviceName: \Device\HarddiskVolume1. (A device which does not exist was specified.)".
|
||||
|
||||
These error messages occurred silently for several hours. Finally, on trying to access a mounted virtual disk inside [[Core|AniNIX::Core]] on 9/18/2016, ArchLinux displayed a cascade of block update failures and required a reboot. All virtual machines on the Forge2 were to be rebooted, but none came up as Hyper-V could not detect the disks. The entire frame was restarted, VM definitions repaired manually, and services restored.
|
||||
|
||||
This issue recurred a few days later and perhaps once a week after.
|
||||
|length=6 hours over a series of downtimes
|
||||
|resolution=Hyper-V resource files and executables were excluded from antivirus scanning. When the antivirus didn't respect this, we dropped antivirus from the Hyper-V host.
|
||||
|commits=[https://aninix.net/mediawiki/index.php?title=Forge2&type=revision&diff=722&oldid=712 Wiki change]
|
||||
}}
|
||||
|
||||
{{DowntimeRCA|Windows Update Service Reboots|cause
|
||||
The Windows Update Service, if it does not see a reboot recently, will reboot the host to install updates. This causes downtimes on the [[Core]] VM and other service VM's; remote recovery has also been made difficult by BIOS randomly changing the boot device.
|
||||
|
||||
Thanks to Mathisen from ##windows on Freenode, we found a GPO we're testing. Set the "gpedit.msc > Computer Configuration \ Administrative Templates \ Windows Components \ Windows Update \ Configure Automatic Updates" option to Enabled and "Notify to download / Notify to install". This should stop automatic reboots but requires a Pro or Enterprise license.
|
||||
|length=2 hours from unattended host
|
||||
|resolution=Apply Group Policy.
|
||||
|commits
|
||||
https://aninix.net/mediawiki/index.php?title=Forge2&type=revision&diff=767&oldid=722
|
||||
}}
|
||||
|
||||
{{DowntimeRCA|Charter ISP Outage|cause
|
||||
At 0043 CST on 11/18/2016, the Charter Residential modem lost connectivity with the wider Internet. Service was not restored until 6:45 a.m., and the admin was physically away from the system. At 1045 CST same-day, a direct check of the IP address luckily showed that the AniNIX had recovered its original IP before the outage.
|
||||
|resolution
|
||||
Admins have changed ISP contracting to be notified immediately of outages and resumption of service.
|
||||
|
||||
The upcoming changes to the [[Cerberus|AniNIX::Cerberus]] project will include detection of changes in WAN IP and will notify admins of changes so that the remote DNS can be updated. Admins will also investigate dynamic DNS services.[[Category:TODO]].
|
||||
|length=6 hours of technical downtime, extended to 10 hours of practical downtime by a lack of reporting tools on ISP outages.
|
||||
|commits
|
||||
* [https://aninix.net/mediawiki/index.php?title=Incident_Response&type=revision&diff=769&oldid=741 Wiki]}}
|
||||
|
||||
{{DowntimeRCA|Windows Sleep Hangs Core VM|cause=Admin Error -- accidentally clicked sleep during RDP disconnect
|
||||
|length=8 hours
|
||||
|resolution=I was able to access the [[Shadowfeed|AniNIX::Shadowfeed]] and [[Forge2|AniNIX::Forge2]] entities by port forwarding through [[Bastion|AniNIX::Bastion]] from my [[Tricorder|AniNIX::Tricorder]], as I was offsite. I was able to restart [[Core|AniNIX::Core]] and supply passphrases to unlock the storage.
|
||||
|
||||
This downtime was exacerbated as I did not check [[Heartbeat|AniNIX::Heartbeat]] after resuming the hypervisor.
|
||||
|
||||
We've added notes for removing sleep options on servers and remote Heartbeat monitoring in response to this incident.
|
||||
|commits=* [https://aninix.net/mediawiki/index.php?title=Forge2&curid=64&diff=984&oldid=932 Wiki for Forge2 notes]
|
||||
* [https://aninix.net/mediawiki/index.php?title=Heartbeat&curid=83&diff=985&oldid=980 Wiki for Heartbeat notes]
|
||||
}}
|
||||
|
||||
{{DowntimeRCA|Windows Wake Hangs Hypervisor|cause=Code issue|length=30 minutes|resolution=All services were restarted.|commits=None yet. I plan to move Bastion to its own host, and to ensure Forge2 runs VMware ESXi rather than Hyper-V. This will take time and planning.}}
|
||||
|
||||
{{DowntimeRCA|Alliant Energy Outage|cause=Power company|length=9 hours|resolution=AniNIX staff noticed connections drop to AniNIX services on 2018-09-18 12:05 CDT. At this point, power had already been out for 22 minutes and UPS power was exhausted, resulting in a shutdown of AniNIX hardware. Alliant notified AniNIX on-site admins 40 minutes later of the outage, and power was restored by 16:00. Unfortunately, AniNIX staff were not able to resume service operation until 21:15.|commits=We will add monitoring either through [[Nazara|AniNIX::Nazara]] or [[Forge2|AniNIX::Forge2]] of the UPS, but this will not prevent an outage. The [[Forge3|rebuild]] may improve uptime capacity, but until a generator is on-premise, this outage is unpreventable. That generator cost will take significant time to defray.}}
|
||||
|
||||
{{DowntimeRCA|Charter ISP Outage|cause=ISP|length=4 hours|resolution=AniNIX on-site admin detected the outage at 2018-10-04 00:05 CDT and restarted modem hardware on-site several times. When this didn't work, the admin contacted the ISP and reported the outage. ISP acknowledged the outage and field techs were sent to repair the outage in the area. Service was restored at 04:10 CDT|commits=None. Our Zapier/Freshping alerting service worked appropriately, and [[Sharingan|AniNIX::Sharingan]] sent out notifications as designed when service resumed.}}
|
||||
|
||||
[[Category:RCA Archive]]
|
10
Operation/Bug_Bounties.md
Normal file
10
Operation/Bug_Bounties.md
Normal file
@ -0,0 +1,10 @@
|
||||
Bug bounties are requests for penetration testing against the AniNIX services.
|
||||
|
||||
# Rules
|
||||
1. Do not test against AniNIX production services without prior authorization. Instead, set up a replica using [ShadowArch](/AniNIX/ShadowArch) and any other AniNIX Foundation repository.
|
||||
1. Report bugs immediately to AniNIX staff via [AniNIX IRC](ircs://aninix.net:6697).
|
||||
1. Control the scope of your pentesting. Using root access to the host to conduct a Direct Memory Access attack on CryptoWorkbench, for example, is not an exploit in that project. Physical penetration is always outside scope.
|
||||
|
||||
# Active Targets
|
||||
## CryptoWorkbench
|
||||
The [CryptoWorkbench](/foundation/CryptoWorkbench) has a --blind option. This is intended to prevent data exfiltration and CLI access, despite being a CLI tool. Install ShadowArch, and use the CryptoWorkbench "make sshuser" command to set up the captive user. If you can use the captive user over SSH to gain a prompt or exfil data through the CryptoWorkbench, please announce it to the admins.
|
75
Operation/Design_Principles.md
Normal file
75
Operation/Design_Principles.md
Normal file
@ -0,0 +1,75 @@
|
||||
The AniNIX is not a collection of one-offs. The following considerations should be evaluated before testing or releasing a new project, and quality assurance should report if any of these design principles aren't met.
|
||||
|
||||
# Meeting the need
|
||||
|
||||
Any design should be evaluated against the need it is intended to meet. Ask the following questions:
|
||||
* Does an existing package fulfill the need better than custom development by the AniNIX? [TheRaven](/AniNIX/TheRaven) is a fairly specialized package, but [Yggdrasil](../Services/Yggdrasil.md) was superior to our self-written Siren and an externally-maintained package, which saves the network human hours.
|
||||
* Is the implementation going to fit the state of the industry? This is a slightly nebulous question, but Bazaar was deprecated in favor of Git for the Foundation project because Git is more widely used and better supported. Following the state of the industry usually means superior features, testing, support, and adoption.
|
||||
* Will filling this need justify the resource expenditure?
|
||||
* Will end users adopt this solution and fill their need that way, or will the effort be wasted when a more professional solution will be released and adopted later?
|
||||
|
||||
# Security-First Design
|
||||
|
||||
## Remote Access vs. Local Only
|
||||
Remote access isn't needed in all cases and opens the network to vulnerabilities. The CryptoWorkbench in the Foundation doesn't need to be remotely accessible when users can deploy their own with git; the Foundation itself doesn't need to allow the world to write to it to allow cooperation. These kinds of projects, that are either read-only or non-deliverable, can be safely monitored with [filesystem intrusion detection](../Services/Cerberus.md), virus scanning, and existing controls over remote access to the host.
|
||||
|
||||
[SSH](../Services/SSH.md) and [IRC](../Services/IRC.md) do allow remote access, and require additional safeguards to those above. Network intrusion detection becomes a need, since this is a means by which attackers can exploit a service. Firewall rules will need to be opened and monitored.
|
||||
|
||||
## Penetration Testing Planning Before Release
|
||||
Identify a plan and set aside resources to test the project before release. Failed attempts at open chroot accounts on [Core](../Entities/Core.md) have been identified and shut down before being generally released; these kinds of attempts allow the AniNIX to have confidence in the released projects while not stifling the developer's ideas. Failed ideas that are insufficiently secured are a good exercise in development, and they can be tabled for later when better controls or designs are available.
|
||||
|
||||
## Appropriate User Rights
|
||||
Running services as root is generally a bad idea for non-security services. Make sure to have a unprivileged account for any other service, particularly if they allow remote access.
|
||||
|
||||
## Physical Access
|
||||
The AniNIX does not believe in the cloud (or, as it is affectionately known, Computers Living On Unknown Datacenters). Cloud computing centralizes storage in a place that is difficult if not impossible for end users to secure and protect; particularly for sensitive information like social security numbers, this is not acceptable. Redundancy of the cloud is also very expensive and hard for small groups to achieve.
|
||||
|
||||
In contrast, if any given user can replicate shared data from the AniNIX and each other on storage that they monitor and secure, the network becomes harder to destroy, impede, or rob. This decentralized model ensures that users know where their data lives, and any given user can stand up the network.
|
||||
|
||||
For services that are hosting information like passwords, the device should be physically secured and the storage encrypted. While they can be made useless by destruction, this should prevent physical access resulting in an immediate compromise.
|
||||
|
||||
## Privacy
|
||||
Guarantees of privacy are a major concern in designs. The AniNIX needs to be able to protect itself while doing its best to provide the same right to others. This ties in with concerns of Remote Access -- remote access that isn't by read-only transport requires an account which can be paired with an individual. This should be used for collaboration with the network and for maintaining user preferences.
|
||||
|
||||
However, tools like documentation and source code should be available from behind privacy tools and without identifying a user. When governments can outlaw information, as many repressive regimes in the Middle East and elsewhere have done, the AniNIX seeks to make sure that the peopke still have power by information.
|
||||
|
||||
Furthermore, any communication across a wwider network should be encrypted. [WebServer](../Services/WebServer.md) controls most of this via the Let's Encrypt SSL certificate for the web apps, but SSH also encrypts its communication. Unencrypted communication is insecure and not private by default and should be prohibited as much as possible.
|
||||
|
||||
# End User Experience
|
||||
|
||||
Services developed in isolation are interesting exercises, but in the end it is the user's comfort and trust in the service that will keep it being used.
|
||||
|
||||
## Reliability and Stability
|
||||
Physical devices should have redundant components and power sources as much as possible. Protections against failures in services, such as frequently saving state and quickly restarting after a failure, are highly encouraged.
|
||||
|
||||
Projects should crash rarely if ever -- any crash should be investigated immediately and the relevant code revisited. Frequent crashes are perhaps the highest cause of end-user dissatisfaction.
|
||||
|
||||
## Performance
|
||||
|
||||
Performance is second only to stability in terms of the end-user experience. Services should be fast and light to meet the needs of users -- the state of development today doesn't tolerate slow and/or intensive processes for all but the most critical projects.
|
||||
|
||||
Ensure that memory is allocated only when needed and deallocated as soon as possible. Processing should use efficient algorithms to meet the goal and should be open to re-evaluation. Network should minimize the use of images in transport -- X11 forwarding and video streaming should only be used in services that the user expects to be noncritical and potentially slow.
|
||||
|
||||
## Graphical Design
|
||||
|
||||
[Minimalism](https://en.wikipedia.org/wiki/Minimalism) is a key principle in the AniNIX design. An uncluttered interface with simple, intuitive options reduce the barrier to entry and improve adoption.
|
||||
|
||||
The AniNIX, as you can see by this page, follows a white-on-black color scheme with red for important or interactive elements. White-on-black results in less light emission from screens, and in low-light conditions this means less effect on the night vision. [A study in August 2013](http://www.jneurosci.org/content/33/32/13081.full) found that white and blue light were the most disruptive to the animal test subjects, while red light was the least. [A LensCrafters study](https://www.lenscrafters.com/lc-us/vision-guide/blue-light-computer-eye-strain?j=2179694&sfmc_sub=150010356&l=175_HTML&u=101219824&mid=6010051&jb=5345&cid=EC-2179694-5/14/2017&&smtrctid=150010356) also found blue disruptive. Red accents, therefore, offer the least disruption while keeping readable text with the highest contrast. The three-color scheme further assists the colorblind, who should still be able to clearly identify the static and interactive elements on the interface.
|
||||
|
||||
GUI elements will generally be deployed by a Web page, as this is a cross-platform means of providing access and easy to code. Should packages choose to include a local GUI, they are responsible for meeting these principles with a best-effort approach.
|
||||
|
||||
## Mobile Access Design
|
||||
With the rise of the smartphone, remotely accessible services should offer a simple means via some app to reduce network traffic. The app interface should be intuitive and quick to use.
|
||||
|
||||
## Etymology
|
||||
|
||||
The AniNIX attaches a unique name, such as Sora for OpenLDAP or Yggdrasil for Emby, to packages and services it instantiates. The reason for this is that the name defines a scope of functionality the AniNIX expects to rely on -- should the underlying package change, such as replacing Plex Media Server with Emby, documenation and AniNIX packages will use the same name.
|
||||
|
||||
Names given should be chosen for relevance to the function being provided (Singularity being a pull service, Foundation being the basis on which we're built, etc.) and for ease of memory. Only the most basic services, such as IRC, WebServer, and SSH, will be left unnamed.
|
||||
|
||||
These names are not intended to supercede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Whereever possible, this should be done via the application's provided interface, such as enabling dark modes. We also should not remove any links that the application provides to its own documentation, licensing, or websites. This means that AniNIX etymology only applies to administrators and is otherwise invisible to end users.
|
||||
|
||||
# Maintainability
|
||||
Make sure that a project can be easily maintained. This means following the Development Best Practices and submitting Markdown documentation for the project.
|
||||
|
||||
Ensure that projects are configurable for key elements, particularly for things like passwords that change often, and they should use well-known and understood languages per the Development Best Practices.
|
34
Operation/Design_Scope.md
Normal file
34
Operation/Design_Scope.md
Normal file
@ -0,0 +1,34 @@
|
||||
I'm defining scope for the various [[:Category:Service|services]] and special-use [[:Category:Entity|entities]]. Use this as a reference for [[Design Principles|design review]]. [[Category:Layout]]
|
||||
|
||||
# Infrastructure
|
||||
* [[SSH]] for read-write access to servers
|
||||
* [[WebServer]] for server read-only and application access
|
||||
* [[Grimoire]] for data storage
|
||||
* [[Shadowfeed]] for networking
|
||||
* [[Infrastructure]] for providing resources like power, cooling, and connectivity to the outside world.
|
||||
* [[Tricorder]] and [[ShadowArch]] for end-user environments.
|
||||
|
||||
# Maintenance
|
||||
* [[Aether]] for backups
|
||||
* [[Heartbeat]] for monitoring
|
||||
* [[Maat]] for regular regressions
|
||||
|
||||
# Security
|
||||
* [[Sora]] for authentication
|
||||
* [[Cerberus]] for intrusion detection/prevention
|
||||
* [[VirusScan]] for malware <!-- TODO roll in with Cerberus -->
|
||||
* [[DedSec]] for penetration testing
|
||||
* [[DarkNet]] for privacy
|
||||
* [[Cerberus]] for testing patches
|
||||
|
||||
# Content
|
||||
* [[Yggdrasil]] for media
|
||||
* [[Wiki]] for documentation
|
||||
* [[Singularity]] for news
|
||||
* [[IRC]] for communication
|
||||
* [[Foundation]] for code
|
||||
|
||||
# Special Interest
|
||||
* [[Geth]] for real-world interaction and automation
|
||||
* [[TheRaven]] for artificial intelligence
|
||||
* [[Holocron]] for portable toolsets.
|
154
Operation/Development_Best_Practices.md
Normal file
154
Operation/Development_Best_Practices.md
Normal file
@ -0,0 +1,154 @@
|
||||
Like all organizations, the AniNIX has a set of coding and development best practices. See [HelloWorld](/AniNIX/HelloWorld) for an example project that should implement these recommendations and provide a skeleton to use.
|
||||
|
||||
# Packages
|
||||
Each package should have a single, dedicated purpose. Developers should be careful against scope creep -- if additional functionality is needed beyond the purpose of the package, another package should be created to fill the need.
|
||||
|
||||
## Commenting
|
||||
All source files should be commented with at least one descriptive comment per operational unit. Ideally, there will be no more than 20 lines between comments, unless so dictated by function. Block comments should be at the beginning of functions summarizing the work the function does, the parameters if any, and the return value if any.
|
||||
```
|
||||
/// <summary>
|
||||
/// Put the summary here
|
||||
/// </summary>
|
||||
/// <param name="xname">A parameter for X</param>
|
||||
/// <param name="yname">A parameter for Y</param>
|
||||
/// <returns>The return value</returns>
|
||||
```
|
||||
|
||||
Source files should also maintain a header block tracking ownership and scope. Some source systems will also require dependency and versioning information in this block. This information is optional; the AniNIX deploys by rolling release, so the PKGBUILD installed into pacman or the Git source repo will have the version. Makefiles and PKGBUILDS will also track dependencies.
|
||||
```
|
||||
/*
|
||||
* File:
|
||||
*
|
||||
* Description:
|
||||
*
|
||||
* Package:
|
||||
* Copyright:
|
||||
*
|
||||
* Author:
|
||||
*/
|
||||
```
|
||||
|
||||
Avoid so-called "code-golfing" in source-code -- source should be easy to read, consistent, and verbose. Comments and other space-consuming elements can be stripped out in compilation for space-conscious projects.
|
||||
|
||||
## Safe Coding
|
||||
All inputs should be sanitized to match the developer's expectations during operations. Unlimited reads are unacceptable -- bound the reads with a buffer to contain the memory pressure to a reasonable space and to prevent overflows.
|
||||
|
||||
All memory that is allocated should be deallocated before the process exits -- zeroing the memory segment is optional.
|
||||
|
||||
## Portability
|
||||
Packages should be reasonably portable to other systems, but there is no expectation of unlimited portability. The network should generally test against ArchLinux -- portable projects should also strive to test against CentOS, Kali Linux, and Windows.
|
||||
|
||||
## External Standards
|
||||
AniNIX projects should follow international standards to ease user interaction.
|
||||
* [Standard keyboard shortcuts](http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts)
|
||||
* [Android](https://developer.android.com/guide/practices/ui_guidelines/index.html) and [Google Web](https://support.google.com/webmasters/answer/35769#1) principles
|
||||
* [Standard command-line options](http://www.tldp.org/LDP/abs/html/standard-options.html)
|
||||
|
||||
## Version Control
|
||||
[Git](../Services/Foundation.md) is the version-control mechanism of choice. Packages being developed by Core admins should be added as a folder immediately under the foundation folder on checkout. Commit messages should be specific, and changes should be attempted in a development branch before being merged to master.
|
||||
|
||||
## Makefiles
|
||||
All packages should include a Makefile with at least the following rules.
|
||||
* compile: This should include all the steps necessary to compile the package. When this is done, the final executable should be able to run from the same directory as the Makefile.
|
||||
* install: This should include all the steps necessary to installed the compiled files to the OS and set appropriate permissions. The compile step should be a dependency.
|
||||
* uninstall: the reverse steps from install
|
||||
* clean: This should remove any files built by compile.
|
||||
* test: this should include the rules needed to run the package without installing.
|
||||
* diff: this should compare local build with installed executables or scripts.
|
||||
* reverse: this should pull the installed copies of scripts back to the source directory
|
||||
* checkperm: make sure permissions are set.
|
||||
Here's a skeleton Makefile to use.
|
||||
```
|
||||
pkgdirname != basename `git config remote.origin.url` | sed 's/.git$$//'
|
||||
|
||||
compile:
|
||||
|
||||
install: compile
|
||||
|
||||
uninstall:
|
||||
|
||||
test: compile
|
||||
python3 -m pytest
|
||||
|
||||
clean:
|
||||
@bash -c 'printf "This will reset the repository and lose all work. Confirm? [YES/no] " ; read answer; [ "$$answer" == "YES" ] && exit 0; exit 1'
|
||||
cat .gitignore | xargs rm -Rf
|
||||
|
||||
diff:
|
||||
|
||||
reverse:
|
||||
|
||||
checkperm:
|
||||
|
||||
```
|
||||
## PKGBUILD
|
||||
Standalone packages like [CryptoWorkbench](/AniNIX/CryptoWorkbench) should include a PKGBUILD for the ArchLinux package manager.
|
||||
|
||||
## Language
|
||||
Filenames should indicate language using standard extensions.
|
||||
|
||||
### bash
|
||||
All OS scripts should be written in bash and include /bin/bash as a dependency.
|
||||
* We don't use CSH/TCSH for [reasons](http://www.grymoire.com/Unix/Csh.html#uh-0).
|
||||
* KSH has other problems.
|
||||
* ZSH is being considered but presently has too low an adoption rate.
|
||||
* Old-school SH is missing features.
|
||||
|
||||
[A style guide](http://www.daveeddy.com/bash/) is available.
|
||||
|
||||
### HTML/CSS/PHP
|
||||
All Web sites should be written in HTML with minimal inline CSS -- a proper stylesheet should be included.
|
||||
* For web pages expected to compile from server execution, PHP should be the chosen language. We have not been able to convert to Facebook's HHVM yet.
|
||||
* For web pages expected to execute functions on the client browser, Javascript should be the chosen language and the Javascript should live in script file.
|
||||
|
||||
### C
|
||||
Low-level applications should be written in C and require /usr/bin/gcc as a dependency. Re-useable functions should be written in linked libraries.
|
||||
|
||||
See man pages for documentation.
|
||||
|
||||
### C#
|
||||
All large-scale applications should be written in C# and include the /usr/bin/mono and /usr/bin/mcs dependencies on compile. C# has been evaluated to be an industry-standard and portable language with a lesser exploit history, superior typing, and better resource management than Java.
|
||||
|
||||
[Documentation](https://docs.microsoft.com/en-us/dotnet/csharp/index) is available.
|
||||
|
||||
### Python3
|
||||
QA and proof-of-concept code should be written in Python3 -- this is a standard among ethical hacking classes, and the programming python3/pdb interfaces make writing code easy.
|
||||
|
||||
[Documentation](https://docs.python.org/3.7/) is available.
|
||||
|
||||
## Integration
|
||||
* Services that do not need to run as a privileged user (notably Cerberus' main HIDS and Heartbeat) should deprivilege.
|
||||
```
|
||||
1. Hook for depriviliging
|
||||
if ! getent passwd raven; then useradd -M -G git,ircd,api -d ${CONFDIR} raven; fi
|
||||
```
|
||||
|
||||
Configuration and installed files should go to the following locations:
|
||||
* Configuration should go into /usr/local/etc/PackageName/
|
||||
* Direct executables should go into /usr/local/bin
|
||||
* Indirect executables, such as compiled Mono projects, should go into /opt/aninix/PackageName/
|
||||
* Logfiles should default to /var/log/PackageName/
|
||||
|
||||
## Code Reuse
|
||||
All projects should seek to maximize code re-use. Any source code that could be generalized should go into [Uniglot](/AniNIX/Uniglot). This repository should be included a dependency in PKGBUILDS and checked by Makefiles.
|
||||
|
||||
## OS Integration
|
||||
|
||||
# Process
|
||||
## Design
|
||||
Projects should be designed with an established scope. This scope should be outlined in the package README.md. The appropriate language should be selected.
|
||||
|
||||
## Development
|
||||
Initial development should be done to get the package in a working condition following the above requirements. The appropriate README.md should be updated with development notes, dependencies, and a wishlist as development proceeds.
|
||||
|
||||
## Peer QA
|
||||
If working with a group or any available peers, these peers should read through the code. Comments should be submitted in Gitea issues or pull requests -- quick conversation can be had on IRC until all is sorted. Until all peer comments are handled to the group's satisfaction, the process will hang.
|
||||
|
||||
## QA
|
||||
All packages should be tested automatically and manually before being released. This should include unit tests for functionality, sanitizing inputs, stability, etc.
|
||||
|
||||
## Release
|
||||
Release via Foundation and preferably also [Maat](https://maat.aninix.net). Web view is provided by AniNIX Foundation, and git cloning programs are available for all major distributions.
|
||||
|
||||
## Bug Reporting and Fixing
|
||||
Bugs should be announced to the network staff via the IRC system. If the bug is geniune, an issue should be created and published to track the resolution. Bug fixes should trump new enhancements and specific fixes tracked as pull requests.
|
21
Operation/Disclaimers.md
Normal file
21
Operation/Disclaimers.md
Normal file
@ -0,0 +1,21 @@
|
||||
Here are some disclaimers end-users should be aware of.
|
||||
|
||||
# Privacy
|
||||
The AniNIX retains minimal information about its users and will not share this information with anyone unless a warrant is issued by the government. We do not buy, sell, trade, or otherwise knowingly disclose personal information.
|
||||
|
||||
The AniNIX offers a best-effort at privacy to its end-users via the security practices, but this is no guarantee against government or corporate eavesdropping or monitoring. You are expected to use good judgement in what you post, contribute, and how you connect to the AniNIX. Please watch our [warrant canary](/AniNIX/WarrantCanary) for our best-effort against interference.
|
||||
|
||||
You can request a review of what information the AniNIX is storing on you in [IRC](ircs://aninix.net:6697).
|
||||
|
||||
These tenants are in line with FFTF's [Security Pledge](https://www.securitypledge.com). We encourage other sites to take it up.
|
||||
|
||||
# Copyright
|
||||
The AniNIX name (serial number 87177883) and the [Core icon](/img/AniNIX.png) (serial number 87177887) are trademarked for the network as Classes 009 (computers), 038 (telecommunications), and 041 (education) trademarks for the name and logo. Please do not create or distribute new products using this name without prior written permission from the admins. They should only be used to credit this network for services rendered.
|
||||
|
||||
All content provided by the AniNIX is provided as-is with no guarantee or warranty. You should review all of a package's source files before installing for completeness and test in a testing VM appropriately.
|
||||
|
||||
All source code is publicly available and free to use -- we encourage everyone to use and modify it as desired. No copyright is placed on the content within this network and may be reproduced with credit. AniNIX source code is licensed under the [WTFPL](http://www.wtfpl.net/about/) -- only the AniNIX name and Core icon are not covered by this license.
|
||||
|
||||
Moreover, the AniNIX subscribes to the [Open Source Way](https://opensource.com/open-source-way) -- anyone is welcome to generate a patch from AniNIX Foundation and submit it, or suggest ideas for Wiki improvements. These can be discussed with our community in [IRC](../Services/IRC.md), and we will maintain an open commit history for both documentation and source code in the interest of transparency. Direct commits to AniNIX resources will require an [AniNIX Sora](../Services/Sora.md) account and are subject to admin review, to prevent security risk to the rest of the community.
|
||||
|
||||
The AniNIX makes use of external source packages, such as MediaWiki, Emby, Tiny Tiny RSS, SSH, SSL, Lighttpd, etc. We make no claim to the source or authorship of these packages -- the AniNIX only offers a means to easily install these other packages. Any etymology of AniNIX services instantiating one of these packages that is not identical to the name of the package is for the ease of use for users administering thier own machines. The AniNIX will not obfuscate the package to hide its original authorship and will limit rebranding to the limits allowed by the package. See [our etymology notes](Design Principles.md#Etymology) for more details.
|
36
Operation/Getting_Started.md
Normal file
36
Operation/Getting_Started.md
Normal file
@ -0,0 +1,36 @@
|
||||
To get started with the AniNIX stack, some familiarity with key concepts and technologies is encouraged.
|
||||
|
||||
# The AniNIX
|
||||
Contributing users should be familiar with the following pages, though these are only a selection of [[:Category:Operation|our operational policies]].
|
||||
* [[User Ethics]] for the integrity required of contributors and users
|
||||
* [[Design Principles]] -- how to design projects
|
||||
* [[Development Best Practices]] for safe project work
|
||||
* [[QANs]] for requesting bug fixes, and [[Bug Bounties]] for ongoing research projects.
|
||||
|
||||
# Basic Applications
|
||||
RSS (Really Simple Syndication) is a format of [https://en.wikipedia.org/wiki/XML XML] files presented over Internet HTTP links. It requires a reader like [[AniNIX::Singularity]], but many sites will have an orange icon with a dot and three curves to indicate their RSS feed -- we have one on our [https://aninix.net/ Root] page.
|
||||
|
||||
IRC or Internet Relay Chat is our primary means of communication. IRC clients connect to an IRC server -- the server also hosts services, such as a channel registry (ChanServ) and nickname reservation (NickServ). Our [[IRC|IRC Wiki page]] has details on clients to connect to our IRC, as well as links to tutorials and a channel mode listing.
|
||||
|
||||
[[Wiki]] is a Web application for community-driven content. Wikipedia maintains a [https://en.wikipedia.org/wiki/Help:Getting_started Getting Started] guide that's excellent reading for new users of the application.
|
||||
|
||||
Git through [[Foundation|AniNIX::Foundation]] is a complicated system. While known as the "stupid content tracker", there are books written on Git for its many features. New users should start with the [https://linux.die.net/man/1/git git] man page and [https://linux.die.net/man/7/gittutorial turorial].
|
||||
|
||||
The shell is the user's primary method of interacting with the OS -- this is done with a local or remote terminal emulator. TLDP has a very [http://tldp.org/LDP/Bash-Beginners-Guide/html/ valuable guide] that new persons should read.
|
||||
|
||||
# Code Development
|
||||
One of my favorite places for learning code development is [https://www.codingame.com/start Codingame], where students are given challenges to solve in their programming language of choice. Compiled code on the AniNIX generally is written in C# or C, and we'd recommend new users choose one of these if they want to contribute to new projects.
|
||||
|
||||
Users should also see [https://www.w3schools.com/ W3Schools] for front-end development through the HTML/CSS/PHP/JavaScript stack for a [[WebServer]]. HTML is used to create the structure of the page, CSS the format of colors etc., PHP for server-side code, and Javascript for client-side code.
|
||||
|
||||
# The Operating System
|
||||
To get started on the operating system, Google:
|
||||
* [http://google.com/search?q=Unix+Basics Unix Basics]
|
||||
* [http://google.com/search?q=OSI+Model OSI Model] and IPv4 Routing
|
||||
* [https://wiki.archlinux.org/index.php/General_recommendations ArchLinux General Recommendations]
|
||||
|
||||
# Learning about Security
|
||||
* Users should try to go through [https://ssd.eff.org/ Surveillance Self-defense] from the Electronic Frontier Foundation.
|
||||
* Younger users can use [[:Category:Google|Google]]'s [https://beinternetawesome.withgoogle.com/en_us Be Internet Awesome].
|
||||
|
||||
[[Category:Operation]]
|
22
Operation/How_to_Get_Involved.md
Normal file
22
Operation/How_to_Get_Involved.md
Normal file
@ -0,0 +1,22 @@
|
||||
The AniNIX is currently recruiting user involvement. As such, we're providing some example background here for new persons, broken down by background. Unless a technical means is provided, your best method of passing along your feedback is [https://aninix.net/irc/ the IRC web client] or [[IRC|your own IRC client]]. Thank you to everyone who is contributing now!
|
||||
[[Category:Operation]]
|
||||
|
||||
# Everyone
|
||||
Everyone should be willing to report issues with AniNIX software, documentation, or provided services -- connect to [[IRC|AniNIX::IRC]] to report these issues. Also sign into this service if you have an idea for new functionality, enhancements or other improvements the AniNIX should be considering!
|
||||
|
||||
# Administrative, Legal, or Business Staff
|
||||
Administrative, legal, or business staff are especially encouraged to review the mission statement, design principles, and development best practices in [[:Category:Operation]]. This is the "business" and "legal" model on which the AniNIX runs and is currently vague in non-technical aspects.
|
||||
|
||||
# Artists
|
||||
Graphic designers are encouraged to review [https://aninix.net/style.css the CSS stylesheet] and [[Special:NewFiles]] to help provide artistic direction. The current aim is a near-terminal like look with white-and-black icons surrounded by red hexagon. Review [[Design_Principles#Graphical_Design|our design principles for graphics]] to understand our motivations and aims. We welcome criticism and debate on these points.
|
||||
|
||||
# Educators
|
||||
Educators will be exceptionally helpful in reviewing documentation. Anything on this Wiki could be reviewed for clarity and understanding. If concepts aren't adequately explained we need to know so that we can link to wider documentation or clarify.
|
||||
|
||||
Of particular interest to educators is [[:Category:Class]]. These are offerings from the AniNIX personnel are used in demos and for teaching, and we could always use review and comments on our methodology.
|
||||
|
||||
# Physical Activity Professionals
|
||||
The [[Martial_Arts/Cardio|cardio]] page could always use new exercises or providers to follow.
|
||||
|
||||
# Technical Personnel
|
||||
These folks are the core of the AniNIX contributing community. This wiki and [https://aninix.net/foundation the Foundation git repo] need review and comments. Submit [[QANs]] as you see the need.
|
21
Operation/Incident_Reports.md
Normal file
21
Operation/Incident_Reports.md
Normal file
@ -0,0 +1,21 @@
|
||||
These are cybersecurity incidents that the AniNIX has had to remedy due to some failure in our detection and prevention systems.
|
||||
|
||||
**Note**: We explicitly exclude routine incidents, such as IP's banned for SSH brute-force, files quarantined after virus scanning, and other routine housekeeping.
|
||||
|
||||
{{Incident Report|Attacker used a default password to pull down a Perl SMTP spambot and email list to spam fake Bank of America emails to users, attempting to phish them into clicking an xplotica link.
|
||||
|title=January 2018 Spambot Detection
|
||||
|date=11-29-2017 through 1-4-2018
|
||||
|who=IRL identity unknown; last source IP 196.52.32.4 (Netherlands residential)
|
||||
|type=Spambot
|
||||
|vector=Attacker used a default password to access a monitoring user account; spambot and target lists were downloaded from a GoDaddy webhost (now nonfunctional).
|
||||
|detect=Detection was provided by the ISP and [https://www.abusix.com/ Abusix]. The Postfix service was shut down, and forensic analysis performed starting with the /var/spool/mail folder.
|
||||
|assets=[[Core|AniNIX::Core]]
|
||||
|impact=This has negatively impacted the AniNIX's reputation as an SMTP source -- we are following up with Abusix and Google to restore our reputation.
|
||||
|
||||
Current forensic investigation does not indicate a compromise to any AniNIX privileged information.
|
||||
|actions=* Monitoring user password has been rotated on all systems.
|
||||
* Automatic password rotation for service accounts added to the ConfigPackages and other repos in [[Foundation|AniNIX::Foundation]]
|
||||
|plan=[[Cerberus|AniNIX::Cerberus]] needs updates to better monitor lastlog output and the sshd "Accepted" regex in journald. Postfix will be evaluated for appropriate MTA settings and restored to service later.
|
||||
|logs=[file:///home/cxford/Desktop/Incident Response - 1-4-2018|Contact an admin for access.]}}
|
||||
|
||||
[[Category:Operation]]
|
67
Operation/Incident_Response.md
Normal file
67
Operation/Incident_Response.md
Normal file
@ -0,0 +1,67 @@
|
||||
# CERT Grab-bag
|
||||
CERT, or Computing Emergency Response Team, is an acronym for first-responders to cybersecurity and computing incidents.
|
||||
|
||||
The FBI maintains a cyber incident reporting service -- should the incident be of a sufficiently malicious nature, it should be reported to the authorities. See [https://www.fbi.gov/file-repository/law-enforcement-cyber-incident-reporting.pdf/view this whitepaper] for a breakdown of how to report.
|
||||
|
||||
CERT individuals should keep a copy of the following things at all times in a grab-bag:
|
||||
* The above whitepaper for FBI contacts
|
||||
* The [https://aninix.net/mediawiki/index.php?title=Template:Incident_Report&printable=yes AniNIX CERT Form]
|
||||
* Copies of [[Category:Layouts|AniNIX layouts]]
|
||||
* Scratch paper and thumb drives for evidentiary capture, along with chain of custody labels
|
||||
<ref name=cisspcertskillset>[https://www.youtube.com/watch?v=PhROeWMPBqU Skillset via YouTube], accessed 1/4/18</ref>
|
||||
|
||||
# Incident vs. Disaster
|
||||
An incident is an unplanned event affecting a service or agency, where a disaster reflects multiple services or agencies.<ref name="linkedinethicalintro">[https://www.linkedin.com/learning/introduction-to-ethical-hacking/information-security LinkedIn Intro to Ethical Hacking Course] by Lisa Bock</ref> A catastrophe is defined as one-step worse -- a destruction of AniNIX software and hardware necessitating rebuilding the same and likely a relocation of any operations and facilities.
|
||||
|
||||
# Required Follow-ups
|
||||
: See TOGAF, COBIT, and ITIL standards for design methods for incident response. Also available is documentation from [https://duckduckgo.com/?q=NIST+Creating+security+plans+for+federal+information+systems&ia=web NIST] on how to formulate security plans.
|
||||
If any disruption of service is caused, an [[RCAs|root-cause analysis (RCA)]] will be filed and users will be notified via [[Singularity|RSS]] and [[IRC]]. Alternatively, cybersecurity incidents will be documented as [[Incident Reports]] and deep-dives can be requested of AniNIX staff.
|
||||
|
||||
As the AniNIX learns of better configuration processes or usage methodology, this Wiki will be updated, which will automatically notify users subscribed to [[Special:RecentChanges]] via RSS.
|
||||
|
||||
Critical patches to AniNIX software and scripts should be added to [[Foundation|AniNIX::Foundation]] immediately with a proper commit message and notifications sent.
|
||||
|
||||
# Service-level incident response
|
||||
The AniNIX maintains onsite [[Security_Layout#Backups|backups]] -- the affected service will be stopped, repaired from best-effort backups, and restarted. Unaffected services will not be disrupted.
|
||||
|
||||
# Software Disaster Recovery
|
||||
Should a collective failure of software occur, all services will be stopped until the damage can be repaired. The AniNIX has onsite backups to this end.
|
||||
|
||||
## ISP events
|
||||
In the event of an ISP event, a redundant method of providing access is available, but some services will be significantly limited or disabled to limit bandwidth usage. If ISP's are unavailable, admins should send the following:
|
||||
|
||||
:Hello, all,
|
||||
|
||||
:Internet access to the network is currently unavailable. To meet with an admin or check on the status, please visit the AniNIX Discord Channel. We will let you know when services are back.
|
||||
|
||||
::**Attach Discord static invite here**
|
||||
|
||||
:Thank you for your patience.
|
||||
:AniNIX Admins
|
||||
|
||||
Admins should also keep a list of [[Sora|registered users]]' emails in a local location -- we recommend storing them in an [[Tricorder|AniNIX::Tricorder]] along with the last known good IP of the AniNIX.
|
||||
|
||||
# Hardware Incident Response
|
||||
In the event of the failure of a redundant or unnecessary hardware component, an admin will:
|
||||
* Review if the hardware needs to be removed. If not, it will be scheduled to be removed on the next downtime and review ends.
|
||||
* Review if the hardware can be removed online. If so, the hardware will be removed as soon as safely possible; all reasonable effort will be made to keep maintenance off-hours.
|
||||
* If none of the above criteria are met and time is available, a notice will be issued at the discovery of the problem and the hardware replaced or repaired off-hours.
|
||||
* If there is no time, hardware will be replaced ASAP and service-providing components restarted. A notice and apology will be issued immediately thereafter.
|
||||
|
||||
Some redundant storage, for example, will be exchanged for failing components.
|
||||
|
||||
# Hardware Disaster Recovery
|
||||
Should hardware critically fail, the AniNIX does not currently have a support agreement with any hardware provider -- overnight shipping and package tracking will be used to offer a best-effort at restoration of hardware. Users should be aware that some non-redundant, expensive hardware may halt service from the AniNIX for up to 48 hours. Should this happen, the AniNIX will re-evaluate the cost of the downtime against the cost of the hardware component.
|
||||
|
||||
If necessary, restoration from the safety-deposit backup will be utilized.
|
||||
|
||||
# Complete Disaster Recovery
|
||||
In the event of a complete disaster, the first line of defense is a hard-drive stored in a safety deposit box with a complete backup of the [[Core|AniNIX::Core]] VM, which includes the source code to rebuild all other machines.
|
||||
|
||||
# Catastrophic Loss Or Attack
|
||||
Should all else have been compromised, a large number of [[Aether|AniNIX::Aether]] nodes will allow rebuilding the system from source code, though there will be a massive loss of data. Some of this will be recoverable over time through file lists stored in the Aether packages, but other data will be lost. This is the last-ditch recovery method.
|
||||
|
||||
AniNIX admins maintain "bug-out" bags for massive environmental, political, or criminal disturbances, with copies of the Aether package on encrypted storage. They are trained to safely self-evacuate and rebuild the network in a safe location. This recovery method will take a long time to effect; users should watch the aninix.net domain name for a return of some IRC daemon with which to use to communicate with admins. As soon as possible, admins will reach out to the userbase to announce when services will be restored, the reason for loss of service, and the extent of data loss.
|
||||
|
||||
# References
|
||||
[[Category:Operation]]
|
6
Operation/Mission_Statement.md
Normal file
6
Operation/Mission_Statement.md
Normal file
@ -0,0 +1,6 @@
|
||||
The mission statement of the AniNIX is simple:
|
||||
1. Provide an example suite of services and serve a small userbase
|
||||
1. Provide documentation and source code to allow anyone to replicate the system.
|
||||
1. Contribute actively to the global community by involvement in the open-source community and charity work.
|
||||
|
||||
[[Category:Operation]]
|
68
Operation/Provisioning.md
Normal file
68
Operation/Provisioning.md
Normal file
@ -0,0 +1,68 @@
|
||||
Provisioning is the process by which new users, services, and hosts are added to the network.
|
||||
|
||||
# Users
|
||||
|
||||
## Notes on Administrative and Daemon Users
|
||||
These users should always be created as local users. Daemon users should be given /sbin/nologin or /bin/false as their login shell to prevent them from doing bad things -- systemd service files will appropriately set UID/GID on processes and shells aren't needed. These daemon users should always have local credentials to be immune to failures in remote services like [[Sora]]
|
||||
* Many services, like IRC, TheRaven, Heartbeat, Sora, and others will use a daemon user at the OS level. These should be local passwords.
|
||||
* At the OS, the admin will be the root user.
|
||||
* SSH should have one deprivileged user that is local.
|
||||
* IRC will have netadmins provisioned with local passwords; these netadmins will need a corresponding LDAP account only for IRCServices. Failure to log in with IRCServices is more acceptable than losing control of the daemon itself. The IRC modules can be unloaded and registration enabled if a local account is needed.
|
||||
* Wiki can only be either LDAP-enabled or local; as we want unified credentials, loss of edit privileges for everyone is acceotable in the case that LDAP has failed.
|
||||
* The following snippet can be used to lock down a specific wiki so only administrators (sysop) can edit.
|
||||
<pre>
|
||||
$wgGroupPermissions['*']['edit'] = false;
|
||||
$wgGroupPermissions['*']['read'] = false;
|
||||
$wgGroupPermissions['user']['read'] = false;
|
||||
$wgGroupPermissions['user']['edit'] = false;
|
||||
$wgGroupPermissions['sysop']['read'] = true;
|
||||
$wgGroupPermissions['sysop']['edit'] = true;
|
||||
</pre>
|
||||
|
||||
## Groups
|
||||
Most groups will be local to a given host; ssh-allow and git permissions will be local, for example.
|
||||
|
||||
LDAP should at least have an ldapuser group to act as the primary group for LDAP users.
|
||||
|
||||
|
||||
## [[Sora]]
|
||||
This project should be the central credential store for end-users on the AniNIX. Below are some notes to help with the setup.
|
||||
|
||||
### [[ShadowArch|OS]]
|
||||
OS Accounts can be added with PAM/NSLCD authentication being enabled. See [https://wiki.archlinux.org/index.php/LDAP_authentication the Arch Wiki] for basic steps to set this up.
|
||||
|
||||
<b>Note:</b> Make sure [[SSH]] services are secured with a required group of ssh-allow before enabling this. See [https://eng.ucmerced.edu/soe/computing/services/ssh-based-service/ldap-ssh-access this link] for how to enable SSH access.
|
||||
|
||||
### [[IRC]]
|
||||
All LDAP accounts are enabled for IRC NickServ access -- the LDAP uid will be the owning nickname. Group membership is allowed, but admins may drop nicks if another user is being created with the uid.
|
||||
|
||||
### [[Wiki]]
|
||||
Wiki's have LDAP groups attached to them; those who will be editors on a given Wiki will be given the Wiki's group to log in with.
|
||||
|
||||
### [[Singularity]]
|
||||
[[Category:TODO]] We are working to integrate the ttrss-ldap-auth-git package from the ArchLinux AUR.
|
||||
|
||||
## [[Yggdrasil]]
|
||||
Yggdrasil currently relies on Plex.tv for account management. Users seeking access to this project will need a Plex.tv account for streaming access. File access can be given with an SFTP jailed account in Sora.
|
||||
|
||||
## Template User Notification
|
||||
Hello, <user>,
|
||||
|
||||
You have a new set of credentials to the AniNIX! Your new user ID is <uid> and your initial password is <password>. Please [[SSH#Available_Clients|SSH]] to <uid>@aninix.net and change your password as soon as possible.
|
||||
|
||||
You now have access to all the [[:Category:Public_Service|public services]] of the AniNIX! Your credentials will work across the board. Please make sure to review [[:Category:Operation|our operational documentation]], particularly the User Ethics page, to understand what the AniNIX is and how to properly contribute.
|
||||
|
||||
If you have any questions, please stop by [https://aninix.net/irc our IRC network] and sign in to NickServ. We'd be happy to talk with you anytime -- admins are indicated with the '@' or '~' sign in the #lobby channel. Again, welcome to the network!
|
||||
|
||||
# Services
|
||||
Services should be provisioned from the [[Foundation]] -- this ensures that standards are followed and a best-attempt is made at security practices. Configure the service post-install to fit your need.
|
||||
|
||||
# Hosts
|
||||
Hosts should be provisioned on an as-needed basis. A default AniNIX network includes the following:
|
||||
* [[Shadowfeed]]
|
||||
* [[Core]]
|
||||
* [[DarkNet]]
|
||||
* [[Bastion]]
|
||||
|
||||
[[Category:Operation]]
|
||||
[[Category:Security]]
|
62
Operation/QANs.md
Normal file
62
Operation/QANs.md
Normal file
@ -0,0 +1,62 @@
|
||||
This is a list of active quality-assurance notes (QANs) being worked on by AniNIX staff. Lists are sorted in order of priority.[[Category:Operation]][[Category:TODO]]
|
||||
|
||||
If you see a problem with our code, go to [https://aninix.net/irc/ IRC] and send a memo to the #tech channel with what you've found. These will be parsed into the ideas list or assigned-QANs lists below by admins.
|
||||
<pre>
|
||||
/ms send #tech <some note>
|
||||
</pre>
|
||||
|
||||
Alternatively, you can make a new page as a child of this one, using [[:Template:QAN]], and assign it to yourself to work on the project. These will appear in [[Category:Open QANs]] automatically for assignment.
|
||||
|
||||
# Ideas
|
||||
|
||||
## GDPR WebApp
|
||||
Add /gdpr WebApp to Webserver to download user content. Look at Sharingan source.
|
||||
|
||||
## Foundation
|
||||
* Finish PKGBUILDs
|
||||
* Identify why CGIT is suppressing "Receiving objects" and other typical git-clone messages.
|
||||
|
||||
## Maat
|
||||
* Look into either using [https://wiki.archlinux.org/index.php/GnuPG GPG keyserver] or adding key fingerprint to [https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys PKGbuilds]
|
||||
* Test Jenkins for E2E, but require Lighttpd auth before proxying app, like Sharingan.
|
||||
|
||||
## Sora
|
||||
* ldap-adduser.bash should make use of 'sed -i "s/^term: /c\term: Newething/" file' to simplify
|
||||
* Improve regexes to handle names like TJ or emails like blar@something.subdomains.jp
|
||||
* Add MemberOf overlay
|
||||
|
||||
<!-- ==ExploitChecks
|
||||
* Add BEAST, BIND, DirtyCOW, CVE-2016-4484, [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456 VENOM], [https://access.redhat.com/security/vulnerabilities/stackguard StackGuard] -->
|
||||
|
||||
## CryptoWorkbench
|
||||
* Update to include flag for suppressing color usage
|
||||
* Update to improve helptext and error checking
|
||||
<!--
|
||||
* Consider ncurses for line recall and better capture of input. [http://curses-sharp.sourceforge.net/API/ Curses Sharp] could do this. MARKING FOR FUTURE -->
|
||||
|
||||
## TheRaven
|
||||
* Add suppress functionality for printing URL headers in conf.
|
||||
* r.in function to remind users/channel in X amount of time with a given message.
|
||||
* r.translate function that acts on the last message and translates with Google translate.
|
||||
* Add PostGres integration
|
||||
* Implement karma system -- nospaces-- or (with spaces)-- should update key
|
||||
* Implement counter system -- r.counter keyword sets timestamp, r.counterdiff keyword returns time delta.
|
||||
* Update searches to allow returning top result if possible. Use searches script folder?
|
||||
* Add random copypasta linker/quoter via URL http://www.bash.org/?random
|
||||
* Discord support
|
||||
* Set attributtes on lists so that r.whitelist/r.blacklist/etc. can be generalized. Steal from CryptoWorkbench subscription model.
|
||||
* Add IQ/word notification so that TheRaven can notify admins of useful conversations via Djinni
|
||||
|
||||
## CSS/.Xresources
|
||||
Because CSS.
|
||||
* Spacing between white borders is inconsistent.
|
||||
* Standardize color requirements between CSS and .Xresource files.
|
||||
* Consider [https://exercism.io exercism.io]'s layout
|
||||
* [[Template:Reference]] has odd spacing of icons in some browsers.
|
||||
* [https://aninix.net/foundation/TheRaven Repo tables] need to include tabulating borders.
|
||||
|
||||
## SSH
|
||||
Consider offering certificate authentication. [https://code.fb.com/security/scalable-and-secure-access-with-ssh/ See Facebook's example.]
|
||||
|
||||
## IRC
|
||||
Write MailServ daemon to proxy emails to MemoServ and allow outbound?
|
4
Operation/RCAs.md
Normal file
4
Operation/RCAs.md
Normal file
@ -0,0 +1,4 @@
|
||||
These are some recent unplanned downtimes on the AniNIX, starting from 8/24/2016. We provide this list and root-cause analyses (RCA's) so that other networks can learn from them or suggest better practices for us to follow. Past years' RCA's are recorded in [[:Category:RCA Archive]].
|
||||
[[Category:Operation]]
|
||||
|
||||
{{DowntimeRCA|Charter ISP Outage|cause=ISP|length=4.5 hours|resolution=AniNIX off-site admin detected the outage at 2019-06-18 16:08 CDT. Phone calls to the ISP confirmed a physical outage. ISP acknowledged the outage and field techs were sent to repair the outage in the area. Service was restored at 20:16 CDT.|commits=Our Zapier/Freshping alerting service worked appropriately, and [[Sharingan|AniNIX::Sharingan]] sent out notifications as designed when service resumed. However, admin staff had run out of coffee -- coffee will be purchased to prevent further outages, as the tech stops working when the coffee runs out.}}
|
5
Operation/Social_Media.md
Normal file
5
Operation/Social_Media.md
Normal file
@ -0,0 +1,5 @@
|
||||
The AniNIX does want to be accessible to end-users, and social media is a global phenomenon that most people are aware of. However, we feel a general distrust for global social media -- self-hosting is optimal for retaining privacy and unifying credentials across services in a way that the AniNIX can protect its end-users.
|
||||
|
||||
Currently, our approach to social media is to identify platforms where we may have an interest in promoting the network, and to establish accounts in those areas with a single post linking back to the AniNIX equivalent. Please see [https://aninix.net/pages/social.php our social index] for accounts and platforms on which we have a presence today.
|
||||
|
||||
[[Category:Operation]]
|
33
Operation/TeamBlue.md
Normal file
33
Operation/TeamBlue.md
Normal file
@ -0,0 +1,33 @@
|
||||
{{Entity|TeamBlue|
|
||||
TeamBlue acts as the defensive side of penetration testing and is the primary testground for [[Cerberus|AniNIX::Cerberus]] and all of [[:Category:Security|our security best-practices]].
|
||||
|word=Blue teams are colored after police and friendly forces in penetration testing exercises.
|
||||
|cap=1 core, 2GB RAM, 30GB hard-drive.
|
||||
|host=TeamBlue should have the extras from Cerberus installed.
|
||||
{{Reference|Cerberus}}{{Reference|VirusScan}}
|
||||
|conn=This box is expected to be attacked by TeamRed. We may add CFEngine for compliance and patching control, and use this machine to test patches before pushing them to Core, Bastion, DarkNet, and Team VM's.
|
||||
{{Reference|Core}}{{Reference|Sora}}
|
||||
|add
|
||||
Watch [https://wiki.archlinux.org/index.php/List_of_applications/Security ArchLinux's Security application list] for tools specific to your use case.
|
||||
|
||||
# Security Essentials
|
||||
Alien Vault recommends the following five security essentials for a "blue" security team.<ref name=avwebcastpci>[https://www.alienvault.com/forms/webcast-thank-you/how-to-simplify-pci-dss-compliance-with-unified-security-management How to Simplify PCI-DSS Compliance with Unified Security Management], accessed 9/7/2017</ref>
|
||||
## Asset Discovery
|
||||
This can be coordinated through a nmap script like below, or through [[Geth|AniNIX::Geth]]'s [https://home-assistant.io/components/discovery/ discovery].module.
|
||||
## Vulnerability Assessment
|
||||
We're looking at a couple candidates for this: [[Category:TODO]]
|
||||
* lynis
|
||||
* OpenSCAP
|
||||
## Intrusion Detection
|
||||
This functionality is provided by [[Cerberus|AniNIX::Cerberus]]. We're considering Tripwire and OSSEC to replace AIDE inside Cerberus.
|
||||
## Behaviorial Monitoring
|
||||
We use [[Heartbeat|AniNIX::Heartbeat]] to set each system's baseline and audit logs for user behavior.
|
||||
## Log Management
|
||||
We're evaluating using [[AniNIX::Bastion]] as a rsyslog host.
|
||||
## Encryption
|
||||
### At rest
|
||||
We use dmcrypt to encrypt files by default at the storage layer via [[ShadowArch|AniNIX::ShadowArch]]
|
||||
### In motion
|
||||
We use [[:Category:SSL|SSL]] for encrypting data in motion.
|
||||
}}
|
||||
# References
|
||||
[[Category:Security]]
|
9
Operation/TeamGreen.md
Normal file
9
Operation/TeamGreen.md
Normal file
@ -0,0 +1,9 @@
|
||||
{{Entity|TeamGreen|
|
||||
TeamGreen runs regular QA regressions and reports results on the [[Foundation|AniNIX::Foundation]] repositories.
|
||||
|word=Similar to [[TeamRed]] and [[TeamBlue]], this box is named for ensuring the quality of AniNIX code.
|
||||
|cap=1 core, 1GB memory, 30GB hard-drive.
|
||||
|host=TeamGreen should host a set of Docker images generated from the ConfigPackages/TeamGreen repo. We are considering using Jenkins to monitor the repo and update regressions, but there are security concerns with that application. TeamGreen code should be written in Python3 using doctest, py.test, hypothesis, and Radon.
|
||||
|conn
|
||||
{{Reference|Foundation}}
|
||||
|add
|
||||
1. See [https://www.digitalocean.com/community/tutorials/docker-explained-using-dockerfiles-to-automate-building-of-images this article] on how to build Docker images for projects.}}
|
8
Operation/TeamRed.md
Normal file
8
Operation/TeamRed.md
Normal file
@ -0,0 +1,8 @@
|
||||
{{Entity|TeamRed|
|
||||
This host acts a penetration testing box.
|
||||
|word=Most high-level organizations have adopted active penetration testing policies. Usually the offensive sector is known as a "red team" as opposed to the defensive "blue team".<ref name=cso>[http://www.csoonline.com/article/2122440/disaster-recovery/emergency-preparedness-red-team-versus-blue-team-how-to-run-an-effective-simulation.html CSO] accessed 6/21/17</ref>
|
||||
|cap=1 core, 2GB RAM, 30GB drive
|
||||
|host=No real services are hosted by this machine. It is an array of tools based on either [https://www.kali.org/ Kali Linux] or the [[ShadowArch]] -k flag. It may make extensive usefulness of the [https://aninix.net/foundation/ExploitChecks ExploitChecks] in AniNIX::Foundation.
|
||||
|conn=This machine targets [[TeamBlue]].
|
||||
|add=}}
|
||||
[[Category:Security]]
|
42
Operation/User_Ethics.md
Normal file
42
Operation/User_Ethics.md
Normal file
@ -0,0 +1,42 @@
|
||||
AniNIX users should follow good ethical principles when using the network. AniNIX resources should be used in accordance with these principles -- activity outside the network is not ours to dictate.
|
||||
|
||||
# Our Mission Statement
|
||||
{{:Mission Statement}}
|
||||
|
||||
# Open Source
|
||||
> Main article on [https://opensource.com/open-source-way OpenSource.com]
|
||||
Open-source means that are willing to provide access to as much information as possible, sharing our experience, work, and assets with the world. (We cannot disclose security tokens and other privileged information for our own self-preservation.) We intend for anyone to take the AniNIX model and inspect it, modify, or enhance it by looking at our documentation and source code. We believe this yields the benefits of control, training, security, and stability to our users, as the more people inspect something the fewer errors are likely to be present.
|
||||
|
||||
# The Hacker Ethic
|
||||
> Main article on [https://en.wikipedia.org/wiki/Hacker_ethic Wikipedia]
|
||||
|
||||
When you give people the means to be creative for themselves and to share their work, they can create beautiful communities of industry and passion. With proper moderation against malice, the human collective evolves, and the AniNIX seeks to include this.
|
||||
|
||||
The AniNIX subscribes to the Hacker Ethic and should build itself to support the same. In order, these are the ideals development in the AniNIX should encourage:
|
||||
* <b>World improvement</b>: The world is not a friendly place to your average person. Compute power can be leveraged to improving people's lives, not just in the pursuit of personal power or profit at the expense of others. Projects within the AniNIX should serve the betterment of the wider world in some fashion or at least some portion of the userbase. We do not use our resources to profiteer from others, particularly their lack of access.
|
||||
* <b>Openness and sharing, particularly open-source</b>: We are world citizens, with equal human rights. Sharing, collaboration, and openness improve the lives of everyone and let us grow as a planet. AniNIX projects and source should be openly available; security keys and credentials may be obfuscated to protect the network.
|
||||
* <b>Decentralization</b>: True democracy is the voice of the people -- the rule of the majority. Too much centralization results in an easy target that can be destroyed by those seeking their own power and profit and to silence opposition. When everyone in the masses has a voice that can't be silenced, they carry immense weight for revolutionizing and improving life.
|
||||
* <b>Equal, free access to computing</b>: The Internet is the last bastion of human free speech and stream-of-consciousness, and open access for everyone gives everyone a voice. Computers allow free educational materials and community-building, and learning to use them promotes intellectualism and self-education. No one should be barred based on race, gender identity, gender expression, sexual orientation, ability, age, cultural identity, IQ, religion, socioeconomic status, etc. -- the sole grounds for blocking access is to prevent specific, malicious actions, such as identity theft, human trafficking, etc.
|
||||
|
||||
## AniNIX Application
|
||||
* The AniNIX provides a number of [[Category:Charity|free-to-access offerings]] in the interest of giving back and we support a number of [https://aninix.net/pages/charity.php charitable organizations] to support the aim of world improvement.
|
||||
* The Wiki and [[Foundation|AniNIX::Foundation]] offer all the documentation and code necessary to replicate AniNIX services.
|
||||
* The Wiki and Foundation combination allow replication of the complete AniNIX suite, allowing for multiple instantiations and decentralized access.
|
||||
* The AniNIX makes as many of its applications Web-accessible as possible to reduce the barrier to entry -- even a public library terminal should have sufficient resources. We also provide the [[ShadowArch]] installer and [[Holocron|AniNIX::Holocron]] project to give everyone access to their own secure computing environment for minimal cost.
|
||||
|
||||
# Good-faith Contributions
|
||||
All contributions to the AniNIX should be done in good faith -- users will not be punished for bad work submitted in an honest fashion. However, in the interest of promoting good faith, they should also be respectful of criticism and advice on how to improve their work. The AniNIX seeks to improve steadily and welcomes debate and discussion.
|
||||
|
||||
If you have concerns or suggestions, please use the talk page of a topic to discuss them.
|
||||
|
||||
# Respect to Peers
|
||||
Please respect your peers in all communication. The AniNIX administrators reserve the right to terminate services at any time to any user found to be disruptive or damaging to the network. We seek a collaborative, not elitist, environment, and all viewpoints should be welcome in a debate.
|
||||
|
||||
# Handling of Malware
|
||||
The AniNIX, being security-minded, handles malware. Please make sure you only transfer malware in secured, inert formats to other users and clearly label it as such so that they know to analyze it.
|
||||
|
||||
The use of malware to attack, harm, or malign the network will not be tolerated. Ensure all testing is done in isolated networks with protected machines to prevent accidental assaults.
|
||||
|
||||
Be sure to read [https://www.law.cornell.edu/uscode/text/18/1030 18 US Code 1030] (thanks to Cornell for providing a copy), particularly section a5A, before distributing or publishing malware source.
|
||||
|
||||
[[Category:Operation]]
|
2
Providers/Category:Anope.md
Normal file
2
Providers/Category:Anope.md
Normal file
@ -0,0 +1,2 @@
|
||||
[https://www.anope.org/ Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:ArchLinux.md
Normal file
2
Providers/Category:ArchLinux.md
Normal file
@ -0,0 +1,2 @@
|
||||
[https://www.archlinux.org/ Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:Avast.md
Normal file
2
Providers/Category:Avast.md
Normal file
@ -0,0 +1,2 @@
|
||||
[Https://avast.com/ Homepage]
|
||||
[[Category:Provider]]
|
3
Providers/Category:Brother.md
Normal file
3
Providers/Category:Brother.md
Normal file
@ -0,0 +1,3 @@
|
||||
http://brother.com/
|
||||
|
||||
[[Category:Provider]]
|
2
Providers/Category:Canonical.md
Normal file
2
Providers/Category:Canonical.md
Normal file
@ -0,0 +1,2 @@
|
||||
[http://www.canonical.com/ Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:Charter.md
Normal file
2
Providers/Category:Charter.md
Normal file
@ -0,0 +1,2 @@
|
||||
[https://charter.com/ Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:Corsair.md
Normal file
2
Providers/Category:Corsair.md
Normal file
@ -0,0 +1,2 @@
|
||||
[Http://corsair.com Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:CyberPower.md
Normal file
2
Providers/Category:CyberPower.md
Normal file
@ -0,0 +1,2 @@
|
||||
[https://cyberpowersystems.com Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:DAREBEE.md
Normal file
2
Providers/Category:DAREBEE.md
Normal file
@ -0,0 +1,2 @@
|
||||
[https://darebee.com DAREBEE] is a free site that offers body-weight and little-equipment workouts -- this is an excellent application of the open-source principle in a non-computing format. Feel free to watch this site for new workouts, either for one-offs or 30-day programs.
|
||||
[[Category:Provider]]
|
4
Providers/Category:DD-WRT.md
Normal file
4
Providers/Category:DD-WRT.md
Normal file
@ -0,0 +1,4 @@
|
||||
DD-WRT is a partially open-source firmware for routers -- it contains both open-source components and proprietary drivers for hardware.
|
||||
|
||||
[http://dd-wrt.com Homepage] and [http://dd-wrt.com/wiki a Wiki] are available to help users configure their own hardware.
|
||||
[[Category:Provider]]
|
2
Providers/Category:EVGA.md
Normal file
2
Providers/Category:EVGA.md
Normal file
@ -0,0 +1,2 @@
|
||||
[Https://evga.com Homepage]
|
||||
[[Category:Provider]]
|
3
Providers/Category:Emby.md
Normal file
3
Providers/Category:Emby.md
Normal file
@ -0,0 +1,3 @@
|
||||
[[Category:Provider]]
|
||||
|
||||
[https://emby.media/ Provider homepage]
|
2
Providers/Category:Foscam.md
Normal file
2
Providers/Category:Foscam.md
Normal file
@ -0,0 +1,2 @@
|
||||
[http://foscam.us/ Home page]
|
||||
[[Category:Provider]]
|
4
Providers/Category:Google.md
Normal file
4
Providers/Category:Google.md
Normal file
@ -0,0 +1,4 @@
|
||||
Google is a provider with which the AniNIX has a love-hate relationship. It provides convenient, Linux-friendly devices in their Androids and Chromecasts, and they provide a number of highly useful Web services. However, they have been caught with [https://thehackernews.com/2017/11/android-location-tracking.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheHackersNews+%28The+Hackers+News+-+Security+Blog%29 privacy violations], and their reach is so extensive as to be a risk to any privacy-minded operation. Users should make choose carefully before using this provider and understand the risks.
|
||||
|
||||
[https://google.com Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:Intel.md
Normal file
2
Providers/Category:Intel.md
Normal file
@ -0,0 +1,2 @@
|
||||
[Http://Intel.com Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:Kingston.md
Normal file
2
Providers/Category:Kingston.md
Normal file
@ -0,0 +1,2 @@
|
||||
[[Http://Kingston.com/ Homepage]
|
||||
[[Category:Provider]]
|
2
Providers/Category:MG%26E.md
Normal file
2
Providers/Category:MG%26E.md
Normal file
@ -0,0 +1,2 @@
|
||||
[http://mge.com/ Homepage]
|
||||
[[Category:Provider]]
|
3
Providers/Category:Nagios.md
Normal file
3
Providers/Category:Nagios.md
Normal file
@ -0,0 +1,3 @@
|
||||
Nagios is a monitoring software company.
|
||||
|
||||
[https://nagios.org Nagios homepage] [[Category:Provider]]
|
5
Providers/Category:Netgear.md
Normal file
5
Providers/Category:Netgear.md
Normal file
@ -0,0 +1,5 @@
|
||||
Netgear is a wireless hardware provider.
|
||||
|
||||
[http://netgear.com/ Homepage] is here.
|
||||
|
||||
[[Category:Provider]]
|
1
Providers/Category:Oracle.md
Normal file
1
Providers/Category:Oracle.md
Normal file
@ -0,0 +1 @@
|
||||
[[Category:Provider]]
|
34
README.md
Normal file
34
README.md
Normal file
@ -0,0 +1,34 @@
|
||||
Welcome to the AniNIX's Wiki. This is the documentation source for the AniNIX network. The implementation details are disclosed here to act as a reference for others and to join the open-source community.
|
||||
|
||||
Any comments, concerns, or suggestions should be submitted as issues.
|
||||
|
||||
# Sections
|
||||
This wiki is divided into sections.
|
||||
* Classes: some classes being taught by AniNIX staff
|
||||
* Entities: a list of hosts, VM's, and hardware used by the network
|
||||
* Operation: a list of policies and procedures for contributing to the AniNIX.
|
||||
* Providers: a list of software, hardware, and service providers
|
||||
* Services: a list of services provided for the network
|
||||
|
||||
# Etymology
|
||||
Wiki, in an [interesting article](http://www.todayifoundout.com/index.php/2010/10/where-the-word-wiki-comes-from/), is cited to mean "quick". This Wiki and many like it are a quick, easily editable and Web-accessible database for presenting information to a wider audience.
|
||||
|
||||
The AniNIX is an open-source, closed-membership network of services available to those known to its admins. Its name is a combination of [animus](http://www.merriam-webster.com/dictionary/animus), meaning governing spirit, and Linux, the platform on which it is built.
|
||||
|
||||
# Relevant Files and Software
|
||||
This Wiki is simply a stream of Markdown files that Foundation will interpret. This makes it similarly simple to edit, fork, branch, and backup.
|
||||
|
||||
# Available Clients
|
||||
Any browser or Git client will sufice.
|
||||
|
||||
# Equivalents or Competition
|
||||
Some real-world equivalents include [Wikipedia](https://en.wikipedia.org/), [FANDOM (formerly Wikia)](https://fandom.com), and the oft-referenced [ArchLinux Wiki](https://wiki.archlinux.org/).
|
||||
|
||||
Rivals include [Encyclopedia Britannica](http://www.britannica.com/) and MSN Encarta.
|
||||
|
||||
We formerly used self-hosted [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki), but we have deprecated that. While it had useful search and templating functionality, we have evaluated that backups, git flow, and offline usability outweigh those benefits.
|
||||
|
||||
# Additional Reference
|
||||
|
||||
The Wiki is considered a charity arm of the AniNIX network -- it is open access to implementation information and the like. This allows others to understand how and why the AniNIX rolled out its projects, and therefore learn from these projects. We hope they will take that information to support their own needs and share their experience in the same fashion. Open access to information therefore improves the world, as all can learn.
|
||||
|
102
Services/Cerberus.md
Normal file
102
Services/Cerberus.md
Normal file
@ -0,0 +1,102 @@
|
||||
The Cerberus project is a physical monitoring solution created to watch through the Eyes and alert the admins.
|
||||
|
||||
# Etymology
|
||||
[http://en.wikipedia.org/wiki/Cerberus Cerberus] was the guardian of the underworld in the Greek mythos. Similarly, this project guards the [[Forge2]] and the daemons on which the AniNIX runs.
|
||||
|
||||
# Relevant Files and Software
|
||||
Cerberus configuration is intensive and manual -- we don't believe automating security installs will be beneficial. The one exception is the [[VirusScan]] package.
|
||||
|
||||
We provide a Makefile in [https://aninix.net/foundation/Cerberus the Cerberus Foundation package] to install all of these.
|
||||
|
||||
## Cerberus Monitors
|
||||
### Command Monitors
|
||||
Example:
|
||||
<pre>
|
||||
[ Filesystem IDS ]
|
||||
type=command
|
||||
command=aide -C | tee /var/log/aide.log
|
||||
interval=86400
|
||||
</pre>
|
||||
Command monitors check for change in command output on a given interval. Each interval, the command will be re-run and checked against the prior output.
|
||||
|
||||
<b>Note:</b> This is not cron-like operation -- the command runs to completion and then we wait the interval. If you need more regular execution, use a File monitor instead, and check for changes in the output file. This may generate more false positives.
|
||||
|
||||
### File Monitors
|
||||
Example:
|
||||
<pre>
|
||||
[ Network IDS ]
|
||||
type=file
|
||||
file=/var/log/suricata/fast.log
|
||||
</pre>
|
||||
|
||||
File monitors use C# API's to watch files for changes. On file change, they will send a notification. FYI, VI'ing a file will cause this to completely re-read the file.
|
||||
|
||||
### Directory Monitors
|
||||
Example:
|
||||
<pre>
|
||||
[ Physical IDS ]
|
||||
type=directory
|
||||
dir=/home/Eyes/Entry/
|
||||
filter=*.jpg
|
||||
</pre>
|
||||
|
||||
Directory monitors watch a directory for changes. The optional filter argument in the configuration allows watching for only specific filetypes.
|
||||
|
||||
## Example Areas to Watch
|
||||
### Vulnerabilities
|
||||
* **System configuration:** The [https://cisofy.com/lynis/ lynis] package offers good monitoring of vulnerabilities, similar to the popular Nessus service.
|
||||
* **Network encryption:** The [https://www.ssllabs.com/ssltest/ Qualsys SSL Labs] test suite provides a dashboard for [[:Category:SSL|SSL certificate and ciphersuite]] health. The AniNIX's scorecard is publicly available at [https://www.ssllabs.com/ssltest/analyze.html?d=aninix.net this link].
|
||||
* **PCI compliance:** Any site handling payment needs to have PCI compliance, primarily for the [https://www.pcisecuritystandards.org Self-Asessment Questionnaire]. The AniNIX attests itself as a PCI SAQ-A site -- all our payment functions are outsourced to PayPal presently or its Venmo subsidiary. We use the [https://pentest-tools.com/website-vulnerability-scanning/web-server-scanner# Pentest-Tools Website Vulnerability Scanning] as our external scan vendor at the moment as a best practice.
|
||||
* **World search availability:** Site domain admins that expect to be found by search engines should maintain a Google Analytics account and watch the [https://search.google.com/search-console Search Console] for issues to remedy on their [[WebServer|webserver]].
|
||||
|
||||
This may be best run as a manual check on a regular basis, rather than as a monitor. We run this battery quarterly to check for posture degradation.
|
||||
|
||||
### Network
|
||||
We recommend and include installation of the [http://suricata.readthedocs.io/en/latest/index.html suricata] package for monitoring network input. Some notes:
|
||||
1. Make sure to get HOME_NET configured correctly.
|
||||
1. Some rulesets need to be dropped.
|
||||
1. tor.rules needs to be removed if you're deploying a [[DarkNet]] machine.
|
||||
1. If you are using IRC, comment out emerging-chat.rules in [file:///etc/suricata/suricata.yaml suricata.yaml].
|
||||
1. I've had some problems with tracking ICMP and UDP, sadly, without millions of false positives. I comment out emerging-icmp.rules and decoder-events.rules
|
||||
1. Streaming services like [[Yggdrasil|AniNIX::Yggdrasil]] sometimes cause stream-events.rules to generate false positives.
|
||||
1. Any other local events should be configured by [file:///etc/suricata/rules/local.rules local.rules]
|
||||
1. You will need to edit suricata.yaml and enable the suricata service yourself -- manual intervention is necessary to make sure the HOME_NET subnet masking is accurate for your deployment.
|
||||
|
||||
To remedy actual assaults, we recommend a response by iptables. At your network edge, use the following commands to add a new drop chain to the firewall.
|
||||
<pre>
|
||||
iptables -N severe
|
||||
iptables -I INPUT -j severe
|
||||
iptables -I FORWARD -j severe
|
||||
</pre>
|
||||
|
||||
When this is done, the following command can be used to block offending IPs.
|
||||
<pre>
|
||||
iptables -A severe -s <SOURCE IP>/32 -j DROP
|
||||
</pre>
|
||||
|
||||
[[Shadowfeed|AniNIX::Shadowfeed]] uses some special iptables syntax -- check [http://www.dd-wrt.com/wiki/index.php/Iptables_command the DD-WRT wiki] for any special considerations.
|
||||
|
||||
Also, we install the [https://aur.archlinux.org/packages/oinkmaster oinkmaster] package to pull rules from Suricata. Update root's crontab to reschedule this job.
|
||||
### Filesystem
|
||||
We recommend using the AIDE package to watch for changes. While the output is complex, we have not found a better system. Please submit a [[QANs|QAN]] if you have recommendations, but we have not had good luck with OSSEC's stability.
|
||||
### Remote Intrusions
|
||||
Presently, we include, configure, and enable the [https://wiki.archlinux.org/index.php/Sshguard sshguard] service to prevent intrusions via iptables. The -s and -p flags on the service file for sshguard control intervals -- see "man sshguard" for details.
|
||||
### Physical Intrusion
|
||||
We recommend adding an eyes user and folders. This user should be SFTP/FTP jailed to their home folder. IP cameras from [[Geth|AniNIX::Geth]] can be configured to upload images to the folders on detecting motion.
|
||||
|
||||
Alternately, Geth units with other sensing equipment can write to files that a File monitor can watch.
|
||||
## Other protections
|
||||
These can be added with "make bonusinstall".
|
||||
### ccrypt
|
||||
Any protected data can be encrypted with ccrypt, a replacement of the popular TrueCrypt software.
|
||||
### pass
|
||||
pass is a Git-aware password storage client using GPG encryption. This is an excellently secure way to store passwords and can integrate directly into the clipboard to never show the password, and it can randomly generate passwords for you. pwgen is an alternative, but you will then need your own password storage system. <b>DO NOT USE TEXT FILES!</b>
|
||||
|
||||
# Available Clients
|
||||
There are no clients for Cerberus -- it will notify any necessary address by email through [[Djinni|AniNIX::Djinni]].[[Category:Djinni]]
|
||||
|
||||
# Equivalents or Competition
|
||||
Professional tools like Nessus, Tripwire, and Check Point provide vulnerability, filesystem, and network scanning. Alternative packages can be browsed from the [https://wiki.archlinux.org/index.php/List_of_applications/Security ArchLinux security tool index].
|
||||
}}
|
||||
[[Category:Internal_Service]]
|
||||
[[Category:Security]]
|
58
Services/Foundation.d/User_Support_Repositories.md
Normal file
58
Services/Foundation.d/User_Support_Repositories.md
Normal file
@ -0,0 +1,58 @@
|
||||
The same concepts used for [[Foundation|AniNIX::Foundation]]'s revision control of code can be used for user home folders.
|
||||
|
||||
# Setup
|
||||
To create this tracking, use the following steps to create a read-write bare Git repo.
|
||||
<pre>
|
||||
cd
|
||||
mkdir .gitbare
|
||||
cd .gitbare
|
||||
git init --bare
|
||||
cd
|
||||
git clone .gitbare test && mv test/.git . && rmdir test
|
||||
</pre>
|
||||
|
||||
You will need to set up the file tracking below -- `git status` at this point will report lots of files that you probably won't want to track, like browser cache, temporary files, and large document files that are better backed up outside revision control.
|
||||
|
||||
# File tracking
|
||||
You will need the following .gitignore added to your repo. This will track SSH keys and config, PGP keys, Weechat config, bash config, git config, TMUX config, rclone config, scripts, Vim config, and a .password-store folder for [[Cerberus|KeePass]] or like password databases.
|
||||
|
||||
Other files are excluded for keeping the repo small enough to be cloned to a [[Tricorder|smartphone]], but they can easily be added if so chosen.
|
||||
|
||||
<pre>
|
||||
1. Ignore normal files
|
||||
*
|
||||
!/.bash_profile
|
||||
!/.bashrc
|
||||
!/bin**
|
||||
!/.git[a-z]*
|
||||
!/.githooks**
|
||||
!/.gpg-id
|
||||
!/.gnupg**
|
||||
!/.password-store**
|
||||
!/.profile
|
||||
!/.rclone.conf
|
||||
!/.ssh**
|
||||
!/.tmux.conf
|
||||
!/.vimrc
|
||||
!/.weechat**
|
||||
!/src
|
||||
/.password-store/kpdb.kdb.lock
|
||||
/.weechat/weechat.log
|
||||
/.weechat/logs
|
||||
/.ssh/known_hosts
|
||||
</pre>
|
||||
|
||||
# Value of Local Branches
|
||||
Some elements, like Git, use default identities for their operation. A local branch can be created at that site to update configurations that need to be site-specific -- if this data shouldn't be moved offsite, the branch needn't be pushed to the remote and can instead be cloned from a backup system directly.
|
||||
|
||||
# Caveats
|
||||
There are some caveats to consider when using this policy.
|
||||
|
||||
## Cloud and Keys
|
||||
Because this system captures SSH keys, PGP keys, and password databases, it is best [[Design_Principles#Physical_Access|not stored in the cloud]]. If you have to store it in the cloud, such as in Google Drive, GitHub, or AWS, you should look at [https://aninix.net/foundation/Aether AniNIX::Aether]'s source code for how to do strong encryption of a tarball of the repo, rather than committing directly to the cloud storage provider. This does, however, carry the intrinsic risk that flaws in the cryptography used can expose the keys to your identity! Don't use the cloud if you can avoid it.
|
||||
|
||||
## Large Files
|
||||
Large files are difficult for revision control systems like this to handle -- they result in large differences for the revision control, which will lengthen clone times, branching, and such.
|
||||
|
||||
## SSH-Only Clones
|
||||
For security, don't put these files onto a Webserver. SSH cloning is mandatory for security, and some ISP's may block residential IP's from getting SSH access.
|
65
Services/Foundation.md
Normal file
65
Services/Foundation.md
Normal file
@ -0,0 +1,65 @@
|
||||
The Foundation is a one-stop shop for source code from AniNIX developers -- it's an open repository form which people can pull source code and recreate the entities being used by the AniNIX. You can view its web frontend from [https://aninix.net/foundation this webpage].
|
||||
|
||||
# Etymology
|
||||
The etymology of the Foundation is twofold. First and foremost, the AniNIX attempts to automate any new package it is using as much as possible, and as such the Foundation holds the very basis on which the AniNIX is built.
|
||||
|
||||
Secondly, the Foundation is the third piece of the charity trinity for the AniNIX, along with the Wiki and the [https://aninix.net/pages/charity.php short-term charity projects]. The AniNIX puts a lot of time into designing its projects and making sure they work. Rather than forcing others to redo this work, we offer commented code and documentation so that the process is transparent but the work-by-hand is minimized.[[Category:Charity]]
|
||||
|
||||
# Relevant Files and Software
|
||||
The Git system was created by the Linux project to manage changes to the kernel and has been on the rise for some time among Version Control Systems (VCS's) with projects like GitHub. The AniNIX self-hosts the repositories in [file:///srv/foundation/ the Foundation server folder] on [[Core]].
|
||||
|
||||
[[WebServer]] is configured to translate the repository to [https://aninix.net/foundation/ the Web-accessible format] via the ArchLinux cgit package. Review the package list at that link and identify the source packages you want to use. Then use the following to clone the source, generally best done to /usr/local/src/ on Linux. Please note that the AniNIX uses Webserver translation to eliminate the need for a .git suffix -- web requests will show in CGIT, while Git clone requests will pull the package all from the same URL. Right-click on your package of choice from the web interface's index page and then clone that address. <pre>
|
||||
git clone https://aninix.net/foundation/<packagename>
|
||||
</pre>
|
||||
|
||||
New packages should make sure to refer to the [[Development Best Practices]] to ensure they are compliant with standards; if you notice an issue with the Foundation's code, make sure to submit a [[QANs|QAN]]. [[TeamGreen|AniNIX::TeamGreen]] should be running regressions on these projects.
|
||||
|
||||
You can use [https://aur.archlinux.org/packages/hexedit-advanced-search/ Hexedit] to edit [file:///usr/share/webapps/cgit/cgit.cgi cgit.cgi] to have a different name, such as "AniNIX::Foundation Web".
|
||||
|
||||
## Dependencies
|
||||
For CentOS, one needs to use the following steps to install Mono. Packages like Cryptoworkbench, Heartbeat, Cerberus, and others require this.
|
||||
* yum install bison gettext glib2 freetype fontconfig libpng libpng-devel libX11 libX11-devel glib2-devel libgdi* libexif glibc-devel urw-fonts java unzip gcc gcc-c++ automake autoconf libtool make bzip2 wget
|
||||
* [https://download.mono-project.com/sources/mono/ Download Mono source]
|
||||
* tar xjvf the source package
|
||||
* configure; make; make install
|
||||
|
||||
*Note:* We used to declare the INSTALLER variable at the top of Makefiles, but no longer do. Non-ShadowArch installs should double check dependencies against the PKGBUILD files manually. We will try to keep this list short.
|
||||
|
||||
# Available Clients
|
||||
To get a client to access the Foundation, use one of the following or visit
|
||||
* ArchLinux: pacman -S git
|
||||
* Ubuntu: apt-get install git
|
||||
* RHEL/CentOS: yum install git
|
||||
* Windows: [https://git-scm.com/download/win Go here], but please be aware that file paths and such are coded for Linux. Windows users will need to conduct extensive code review to install these packages.
|
||||
* Mac: [https://git-scm.com/download/mac Go here]
|
||||
|
||||
Each package will need to be checked out individually.
|
||||
|
||||
**Alternatively**: ArchLinux users can add the following segment to the bottom of pacman.conf to install the packages as bundled by the AniNIX. We're working on adding GPG signing -- in the meantime, security-conscious users should build from source anyway.
|
||||
<pre>
|
||||
[AniNIX::Foundation]
|
||||
SigLevel = Optional TrustAll
|
||||
Server = https://aninix.net/foundation/
|
||||
</pre>
|
||||
|
||||
# Equivalents or Competition
|
||||
The most famous equivalent is [https://github.com GitHub]. Other source code control systems exist, including some provided by employers or academic institutions -- GitLab provides an enterprise-style implementation. Other protocol implementations vary widely -- Mercurial, Bazaar, and SVN are other revision control systems others use. We appreciate the flexibility of Git.
|
||||
|
||||
# Additional Reference
|
||||
Some core Git tools are leveraged in specific ways for the AniNIX.
|
||||
|
||||
## Config for Author
|
||||
Even though the [[Talk:IRC#Why_Not_SMTP|AniNIX doesn't use SMTP]], we still use the @aninix.net suffix for the user.email config property on branches. All commits, therefore, should have the proper-case of the user's [[IRC|AniNIX::IRC]] handle as the user.name attribute, and the lower-cased username followed by @aninix.net for the user.email attribute.
|
||||
|
||||
## Tags for Semantic Versioning
|
||||
We version our projects according to [https://semver.org/ Semantic Versioning] -- this versioning is established using the git tag as major and minor version, the git commit as the patch, and the number of commits since the tag as the ArchLinux release note.
|
||||
|
||||
[https://aninix.net/cgit/cgit.cgi/HelloWorld/tree/PKGBUILD Our HelloWorld PKGBUILD] demonstrates this -- most of the metadata for the package is populated directly by git, and only dependencies are tracked in the PKGBUILD itself.
|
||||
|
||||
## Branches for Functional Improvements
|
||||
All major functional improvements being worked should be tracked in a branch. The branch name should be the same as the [[QANs|QAN]] for which the branch was started or the functional concept's shortname.
|
||||
|
||||
## Filter-branch to Prune
|
||||
Git maintains a history of all files. If you need to remove files permanently, GitHub maintains [https://help.github.com/articles/removing-sensitive-data-from-a-repository/ an article] on how to use "git filter-branch" to purge it.
|
||||
}}
|
||||
[[Category:Public_Service]]
|
28
Services/Geth.d/HailPIre.md
Normal file
28
Services/Geth.d/HailPIre.md
Normal file
@ -0,0 +1,28 @@
|
||||
# Hardware
|
||||
* Exacto knife
|
||||
* Superglue
|
||||
* Screwdriver
|
||||
* [https://smile.amazon.com/gp/product/B011RBJUOC/ref=oh_aui_detailpage_o07_s02?ie=UTF8&psc=1 Maker case]
|
||||
* [https://smile.amazon.com/gp/product/B01GH03ZCQ/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1 SainSmart Tumbling Two-wheels R/C Car]
|
||||
* [https://smile.amazon.com/gp/product/B014KMHSW6/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1 Motor controller]
|
||||
* [https://www.amazon.com/gp/product/B008BHAOQO/ref=oh_aui_detailpage_o07_s01?ie=UTF8&psc=1 5V stepper]
|
||||
* [https://www.newegg.com/Product/Product.aspx?Item=9SIA5YB4AM9292 Raspberry Pi 3]
|
||||
* 3 red LEDs
|
||||
* [https://www.newegg.com/Product/Product.aspx?Item=9SIA7BF34K1148 RPi camera]
|
||||
* 2 [https://www.newegg.com/Product/Product.aspx?Item=9SIADD85RA7446 IR rangefinders]
|
||||
|
||||
# Construction
|
||||
|
||||
## Body
|
||||
|
||||
## Wiring
|
||||
* See [https://diyhacking.com/raspberry-pi-robot/ this article for wiring schematics].
|
||||
* We are also considering [http://www.eng.fiu.edu/mme/robotics/elib/FCRAR2012-Wireless-Self-Charging-Robot.pdf wireless self-recharging].
|
||||
|
||||
## Code
|
||||
|
||||
# Operation
|
||||
|
||||
# Gallery
|
||||
|
||||
# References
|
30
Services/Geth.d/Hardware.md
Normal file
30
Services/Geth.d/Hardware.md
Normal file
@ -0,0 +1,30 @@
|
||||
These are some purpose-built hardware we are using with the Geth gestalt. Please keep in mind that we are also tracking code projects for [[Geth/Hub|Geth Hub]], [[Geth/Nazara|Nazara]], and [[Geth/Armature|Armature]] units as well.
|
||||
|
||||
# Chromecast Displays
|
||||
Chromecasts are very easy to set up -- connect the Chromecast to the HDMI and power-over-USB slots in some TV. Use the Chromecast app native to [[Tricorder|Android]] devices to set it up to connect to a [[Shadowfeed|AniNIX::Shadowfeed]]. The Geth [https://home-assistant.io/components/discovery/ discovery] module will pick up the display's presence, and devices can then cast over WiFi.
|
||||
|
||||
[[ShadowArch]] hosts will need the following firewall rules:
|
||||
<pre>
|
||||
CHROMECAST_IP=YOUR_/24_HOME_SUBNET_CIDR
|
||||
iptables -A INPUT -s ${CHROMECAST_IP} -p udp -m multiport --sports 32768:61000 -m multiport --dports 32768:61000 -m comment --comment "Allow Chromecast UDP data (inbound)" -j ACCEPT
|
||||
iptables -A OUTPUT -d ${CHROMECAST_IP} -p udp -m multiport --sports 32768:61000 -m multiport --dports 32768:61000 -m comment --comment "Allow Chromecast UDP data (outbound)" -j ACCEPT
|
||||
iptables -A OUTPUT -d ${CHROMECAST_IP} -p tcp -m multiport --dports 8008:8009 -m comment --comment "Allow Chromecast TCP data (outbound)" -j ACCEPT
|
||||
iptables -A OUTPUT -d 239.255.255.250 -p udp --dport 1900 -m comment --comment "Allow Chromecast SSDP" -j ACCEPT
|
||||
</pre>
|
||||
|
||||
Hubs can also be implemented to replace IR remotes.
|
||||
|
||||
# Ring Cameras
|
||||
|
||||
# Nest Smoke Detectors
|
||||
|
||||
# Chamberlain Garage Door Openers
|
||||
|
||||
# Wink Door Switches
|
||||
|
||||
# TPLink Power Sockets
|
||||
|
||||
# iRobot Roomba
|
||||
Register the unit with [https://homesupport.irobot.com/rd?1=AvMk~wouDv8S~xb~Gv9W~yIJ6GcqyU77x1xaZD7~Pv_T&2=27849 the care center] for warranty support, tips and tricks, and parts availability.
|
||||
|
||||
# Lasko Heater (CAUTION)
|
51
Services/Geth.d/Hub.md
Normal file
51
Services/Geth.d/Hub.md
Normal file
@ -0,0 +1,51 @@
|
||||
Geth hubs are the most prototypical unit. They are basic control and data providers to the Geth gestalt.
|
||||
|
||||
# Typical Install
|
||||
Installation:
|
||||
* [https://www.raspberrypi.org/downloads/raspbian/ Download the latest image.] [[Category:Raspberry Pi]]
|
||||
* Buy a Raspberry Pi, microUSB 5V/4A power supply, and micro SD card 8GB or more in capacity.
|
||||
* Attach the SD card to some Linux system.
|
||||
* dd bs=4M if=*raspbian*.img of=/dev/<SD Card>
|
||||
* Mount the /dev/sda2 partition to /mnt and /dev/sda1 partition to /mnt/boot
|
||||
* "scp /usr/local/src/ConfigPackages /mnt/usr/local/src/"
|
||||
* "chroot /mnt"
|
||||
* "cd /usr/local/src/ConfigPackages/Geth"
|
||||
* "make rpi-base"
|
||||
|
||||
## Remotes
|
||||
* Purchase an [https://www.newegg.com/Product/Product.aspx?Item=9SIA7BF2K18332 IR shield] and attach it to your GPIO pins.
|
||||
* "make remote" from /usr/local/src/ConfigPackages/Geth on the Pi.
|
||||
* [http://ozzmaker.com/how-to-control-the-gpio-on-a-raspberry-pi-with-an-ir-remote/ Set up LIRC to read and write from the shield.] This [https://raspberrypi.stackexchange.com/questions/50873/lirc-wont-transmit-irsend-hardware-does-not-support-sending article] may have more troubleshooting help.
|
||||
* Use [http://www.lirc.org/html/irrecord.html irrecord] to capture the sequences from the current remote.
|
||||
* At a minimum, capture power, input, enter, mute, volume up and volume down from your TV.
|
||||
* DVD players and such devices may need more captures.
|
||||
* Roombas only need launch, dock, and spot-clean commands. [https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/irobot/Roomba.lircd.conf These are already captured].
|
||||
* Use irsend to test sending commands.
|
||||
* Set up the proper SSH keys and ~/.ssh/config options to allow the hass user to SSH to the Pi without a password.
|
||||
|
||||
The following snippet added to your configuration.yaml to allow remote-like activity.
|
||||
<pre>
|
||||
switch:
|
||||
- platform: command_line
|
||||
switches:
|
||||
mainpower:
|
||||
command_on: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_POWER"
|
||||
command_state: 'ping -c 1 mainchromecast.aninix.net | grep -c "1 received"'
|
||||
command_off: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_POWER"
|
||||
cover:
|
||||
- platform: command_line
|
||||
covers:
|
||||
mainvolume:
|
||||
command_open: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_VOLUMEUP"
|
||||
command_stop: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_MUTE"
|
||||
command_close: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_VOLUMEDOWN"
|
||||
#icon: mdi:volume-medium
|
||||
maininput:
|
||||
command_open: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_CONFIG"
|
||||
command_stop: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_ENTER"
|
||||
command_close: "ssh -o StrictHostKeyChecking=no -q pi@geth-host-1 irsend SEND_ONCE NS-RC4NA-14 KEY_CONFIG"
|
||||
#icon: mdi:animation
|
||||
</pre>
|
||||
|
||||
## Cameras
|
||||
A package, motion, provided by Raspbian allows use of [https://www.raspberrypi.org/products/camera-module-v2/ cameras], which are more secure than oft-compromised off-the-shelf IP cameras.
|
13
Services/Geth.d/Nazara.md
Normal file
13
Services/Geth.d/Nazara.md
Normal file
@ -0,0 +1,13 @@
|
||||
# Installation
|
||||
|
||||
Nazara hosts should follow the [[Geth/Hub|typical hub base installation]], but they don't need any hardware besides a [[:Category:Raspberry_Pi|Raspberry Pi 3]][[Category:Raspberry_Pi]] and 5V/4A power supply.
|
||||
|
||||
The deprivileged user on the Nazara host should set up the [[SSH|/home/pi/.ssh]] folder with configs and keys for each critical and service host in the ecosystem.
|
||||
|
||||
1. Create the key:<pre>ssh-keygen -t rsa -b 4096 -N PASSPHRASE -f USER-HOST</pre>
|
||||
1. Install the key to a new host:<pre> ssh-copy-id -i /home/pi/.ssh/USER-HOST USER@HOST</pre>
|
||||
1. Regularly rotate all the key passphrases:<pre>for i in `ls -1 /home/pi/.ssh | egrep -v 'known_hosts|config|authorized_keys|.pub$'`; do ssh-keygen -p -P OLDPASS -N NEWPASS -f "$i"; done</pre>
|
||||
|
||||
# Etymology
|
||||
|
||||
In the Mass Effect universe, the Geth were secretly puppeted by an ancient AI, a Reaper also known as Sovereign or Nazara. A Nazara Geth node similarly manipulates all the nodes in the ecosystem.
|
20
Services/Geth.md
Normal file
20
Services/Geth.md
Normal file
@ -0,0 +1,20 @@
|
||||
Geth is a complete automation suite for homes and interaction with the physical world. However, it is not a automatic process, and as such you will need to install it manually.
|
||||
|
||||
# Etymology=The [http://masseffect.wikia.com/wiki/Geth Geth] are a fictional race in the Mass Effect universe. Geth are individual processes running on many platforms. The more devices, the smarter the collective or gestalt consciousness of the entity becomes.
|
||||
|
||||
# Relevant Files and Software
|
||||
You can install Geth with [https://aninix.net/foundation/ConfigPackages ConfigPackages]'s Geth Makefile and configuration.
|
||||
|
||||
A number of devices can be controlled under the gestalt -- see [[Geth/Hardware]] for our experiments with Geth hardware platforms. The configuration.yaml format used by the underlying home-assistant package is very simple, and as such we don't prescriptively install one over the base version. Instead, we include snippets for you to define your own structure.
|
||||
|
||||
We are also considering features such as integrating smart lights with Shadowfeed presence detection and timeslots and requiring wireless presence for RFC door unlocks.
|
||||
|
||||
[file:///var/lib/hass/ Geth configuration] can be tested with the following: <pre> hass --script check_config -c /var/lib/hass</pre>
|
||||
|
||||
# Available Clients
|
||||
See [[WebServer#Clients|this list of clients]] for tools to access this system. The Shadowfeed NAT rules will need to be updated to allow access outside the network, and make sure to follow [https://home-assistant.io/getting-started/securing/ the security checkpoints] before publishing.
|
||||
|
||||
# Equivalents or Competition
|
||||
Most home-automation systems are DIY at the moment, though the [https://nest.com/ NEST] system is one commercial offering.
|
||||
<!--|ref=REFERENCE-->}}
|
||||
[[Category:SSL]]
|
27
Services/Grimoire.md
Normal file
27
Services/Grimoire.md
Normal file
@ -0,0 +1,27 @@
|
||||
Grimoire is a PostgreSQL[[Category:PostgreSQL]] database underlying other systems on the AniNIX, including [[Singularity]] and [[Wiki]].
|
||||
|
||||
# Etymology
|
||||
A [http://en.wikipedia.org/wiki/Grimoire grimoire] is historically a collection of magical knowledge and the ability summon spirits or daemons. Similarly, Singularity adds knowledge to be read from the Grimoire, and Wiki includes the methodology to start the daemon processes being run on the network.
|
||||
|
||||
# Relevant Files and Software
|
||||
Grimoire has a user, postgres, with a home directory of [file:///var/lib/postgres/ /var/lib/postgres/]. This user's bashrc contains some help text on how to reset passwords and backup databases in PostgreSQL.
|
||||
## Backups
|
||||
Backups are provided by [[Aether|AniNIX::Aether]]. They can be restored with the following:
|
||||
<pre>
|
||||
psql -U dbuser -d db -f backup.sql
|
||||
</pre>
|
||||
|
||||
# Available Clients
|
||||
There are no clients for the Grimoire -- Singularity and Wiki maintain their tables.
|
||||
|
||||
# Additional Reference
|
||||
Make sure to read the [https://wiki.archlinux.org/index.php/PostgreSQL PostgreSQL page on ArchWiki] to understand how to maintain this system.
|
||||
# Tables
|
||||
* Singularity controls the ttrss database.
|
||||
* Wiki controls the wiki database.
|
||||
<!--
|
||||
* WikiGB controls the wiki-gb database. This database is internal-only.
|
||||
* ACWiki-Archive controls the acwiki-archive database.
|
||||
-->
|
||||
}}
|
||||
[[Category:Internal_Service]]
|
152
Services/IRC.d/IRC_Commands_and_Modes.md
Normal file
152
Services/IRC.d/IRC_Commands_and_Modes.md
Normal file
@ -0,0 +1,152 @@
|
||||
|
||||
## Basic Commands
|
||||
: Borrowed from [https://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial the Wikipedia tutorial]
|
||||
|
||||
Users should also type "/msg NickServ help" into their client for help with nickname questions or user preferences, or use "/msg ChanServ help" for help with registering and administering channels.
|
||||
|
||||
{| class="wikitable"
|
||||
!Command || What it does || Example
|
||||
|-
|
||||
|/attach <br/> /server || Sign on to a server || **/attach** chat.freenode.net <br/> **/server** chat.freenode.net
|
||||
|-
|
||||
|/nick || Set your nickname || **/nick** YourName
|
||||
|-
|
||||
|/join || Join a channel || **/join** #en.wikibooks
|
||||
|-
|
||||
|/part || Leave a channel || **/part** #en.wikibooks
|
||||
|-
|
||||
|/msg || Sends a message (can either be private or to the entire channel) || Message the channel: **/msg** #en.wikibooks Hello, World! <br/> Send a private message: **/msg** JohnDoe Hi, John.
|
||||
|-
|
||||
|/whois || Display information about a user on the server || **/whois** JohnDoe
|
||||
|-
|
||||
|/clear <br/> /clear all || Clears a channel's text. <br/> Clears all open channel's text. || **/clear** <br/> **/clear all**
|
||||
|-
|
||||
|/away || Sets an away message. **Note: Type /away again to return from away.** || **/away** I'm away because...
|
||||
|-
|
||||
|/me || Sends an action to the channel. See example. || The following: <br/> **/me** loves pie. <br/> would output to the chat in the case of JohnDoe: <br/> **JohnDoe** loves pie.
|
||||
|-
|
||||
|/quit || Disconnects you from the IRC network. You can also quit with a quit message. || **/quit** Off to bed.
|
||||
What happens: JohnDoe has quit (Off to bed)
|
||||
|}
|
||||
|
||||
## Channel Modes
|
||||
<p>Channel modes allow you to change the way the channel reacts to certain events. All channels have modes +nt set on them by default. To change a channel mode, simply enter:</p>
|
||||
<pre>/mode #channel +m</pre>
|
||||
<p>Keep in mind that Channel Modes are case sensitive, +b and +B are NOT the same thing. All the time codes do not have to be in seconds, if you want to do a 10 minute ban, rather than using "600" for your time, you can do "10m". Supported time codes are:<br> 1y2m3w4d5h6m<br>Below is a list of Channel Modes supported by InspIRCd:</p>
|
||||
|
||||
### Core Modes
|
||||
{||class="wikitable"
|
||||
|-
|
||||
|b [n!u@h]||Bans matching [n!u@h] from joining the channel. Also, be sure to check out the <strong>extbans</strong>.
|
||||
|-
|
||||
|i||Sets the channel as Invite-Only
|
||||
|-
|
||||
|k [key]||Sets a key on the channel.
|
||||
|-
|
||||
|l [number]||Sets the channel limit to [number]. Once the limit is reached, no more users can join.
|
||||
|-
|
||||
|m||Makes a channel "moderated". Only +qaohv can talk. (You must have at least a voice to talk)
|
||||
|-
|
||||
|n||Forces a user to be in the channel to PRIVMSG it. You probably want to keep this mode.
|
||||
|-
|
||||
|o [nick]||Makes [nick] a channel Operator.
|
||||
|-
|
||||
|p||Sets the channel as 'private'. Will not show up in /LIST, but WILL still show up in your WHOIS.
|
||||
|-
|
||||
|s||Sets the channel as 'secret'. Will not show up in /LIST or /WHOIS, generally preferred over +p
|
||||
|-
|
||||
|t||Forces a user to have +o or +h to change the topic. You probably want to keep this mode.
|
||||
|-
|
||||
|v [nick]||Gives voice to [nick]. Voiced users have no real power, the only thing special about being voiced is being able to speak when mode +m is set.
|
||||
|}
|
||||
|
||||
### Modular Modes
|
||||
These modes are available through modules. Once the module is unloaded, modes will be removed, and their effects gone.
|
||||
{||class="wikitable"
|
||||
|-
|
||||
|A||allowinvite||Allows all users in the channel to use /INVITE, even if they don't have half-op or above.
|
||||
|-
|
||||
|a||chanprotect||Gives protected status to [nick]. This protects them from channel ops (+o); as of 2.0, this now implies +o.
|
||||
|-
|
||||
|B||blockcaps||Blocks messages with too many CAPITAL LETTERS. The amount of capital letters that is decided to be too many is set by the network configuration.
|
||||
|-
|
||||
|C||noctcp||Blocks CTCPs to the channel.
|
||||
|-
|
||||
|c||blockcolor||<strong>Blocks</strong> messages and notices with colour or formatting codes. Also see chanmode +S.
|
||||
|-
|
||||
|D||delayjoin||Users are not shown as joined until they speak.
|
||||
|-
|
||||
|d [sec]||delaymsg||Disallows a user from talking in the channel unless they've been joined for [num] seconds.
|
||||
|-
|
||||
|e [n!u@h]||banexception||Allows users matching [n!u@h] to bypass +b
|
||||
|-
|
||||
|F [num]:[sec]||nickflood||Allows only [num] nick changes every [sec] seconds in a channel.
|
||||
|-
|
||||
|f {*}[num]:[sec]||messageflood||Allows only [num] messages from a user every [sec] seconds. Exceeding this will enact a KICK on the offending user (or ban if the * is included.)
|
||||
|-
|
||||
|G||censor||Censors bad words from the channel based on network configuration.
|
||||
|-
|
||||
|g [keyword]||chanfilter||Blocks messages matching [keyword]. Wild cards are usable here; however, must be done with wildcards surrounding the keyword as well. For example, if you wanted to filter [key*word], you would type: <strong>/mode +g *key*word*</strong>
|
||||
|-
|
||||
|H [num:sec]||chanhistory||Displays the last [num] lines of chat to a user joining a channel; [sec] is the maximum time to keep lines in the history buffer. Designed so that the new user knows what the current topic of conversation is when joining the channel.
|
||||
|-
|
||||
|h [nick]||halfop||Makes [nick] a channel Half-Operator
|
||||
|-
|
||||
|I [n!u@h]||inviteexception||Allows users matching [n!u@h] to bypass +i
|
||||
|-
|
||||
|J [sec]||kicknorejoin||Disallows a user from joining [sec] seconds after being /KICK'd
|
||||
|-
|
||||
|j [num]:[sec]||joinflood||Allows only [num] users to join the channel in [sec] seconds.
|
||||
|-
|
||||
|K||knock||Disallows usage of /KNOCK on the channel.
|
||||
|-
|
||||
|L [channel]||redirect||When the channel is "full" (from channel mode "l"), forwards the user to [channel].
|
||||
|-
|
||||
|M||services_account||Users must be registered with services to speak in the channel.
|
||||
|-
|
||||
|N||nonicks||Disallows nick changes for users on the channel.
|
||||
|-
|
||||
|O||operchans||Marks a channel as an oper-only channel; only users who are oper'ed will be able to join these channels. As well, only opers may set channel mode +O.
|
||||
|-
|
||||
|P||permchannels||Marks the channel as "permanent". Will not disappear when there are no users. Note that only opers can set this mode.
|
||||
|-
|
||||
|Q||nokicks||Disallows channel kicks, except Services / U-Lined clients.
|
||||
|-
|
||||
|q||chanprotect||Makes [nick] a channel owner. Protects from +a and +o; as of 2.0, this now implies +o.
|
||||
|-
|
||||
|R||services_account||Users must be registered with services to join the channel.
|
||||
|-
|
||||
|r||services_account||Marks a channel as registered. While some services still use this (namely Anope), this mode is mostly depreciated.
|
||||
|-
|
||||
|S||stripcolor||<strong>Strips</strong> colour or formatting codes from messages and notices to the channel. Note that the user sending the message will still see the colour and/or formatting. Also see chanmode +c.
|
||||
|-
|
||||
|T||nonotice||Blocks /NOTICEs to the channel.
|
||||
|-
|
||||
|u||auditorium||Creates an "Auditorium" channel.
|
||||
|-
|
||||
|w [flag]:[banmask]||autoop||Adds basic channel access controls of [flag] to [banmask], via the +w listmode. For example, +w o:R:Brain will op anyone identified to the account "Brain" on join.
|
||||
|-
|
||||
|X [flag]:[restriction]||exemptchanops||Allows the level of channel access required to bypass a given permission to be set. For example, setting +NX v:nonick will prevent people from changing nicks unless they are voiced (or opped/halfopped).
|
||||
|-
|
||||
|Y||ojoin||Marks a user as an oper in-channel with a definable prefix in front of their nick, when an oper issues the <strong>/ojoin #channel</strong> command. An oper with +Y cannot be kicked or deoped. Note that this mode is oper only.
|
||||
|-
|
||||
|y||operprefix||Marks a user as an oper in-channel with a definable prefix in front of their nick. If this module is loaded, all opers will permanently be prefixed with the character, as opposed to +Y, which only prefixes during an /ojoin. Note that this mode is oper only.
|
||||
|-
|
||||
|Z||namedmodes||This module allows for the display and manipulation of channel modes via long-form mode names. For example, to set a channel ban with named modes: <pre>/MODE #channel +Z ban=foo!bar@baz</pre>
|
||||
|-
|
||||
|z||sslmodes||All users must be connected to the network via SSL to join the channel.
|
||||
|}
|
||||
|
||||
### Recommended Mode Settings
|
||||
ChanServ will by default set modes "keeptopic peace cs_secure securefounder secureops topiclock persist cs_keep_modes signkick topiclock" on any registered channel. NickServ adds +r to any registered user, and first user to join a channel will be founder. Here are some other recommendations.
|
||||
1. Private channels should receive mode +Rs or +Ris to prevent unwanted visitors.
|
||||
1. Network-maintained channels should get the ChanServ no-expire setting -- user-defined channels should not.
|
||||
1. Hierarchy in the channel should be laid out according to the following:
|
||||
1. Channel founders (and successors if any) should be in the ChanServ qop list and have mode +q. Network-maintained channels should have an IRC NetAdmin as channel founder.
|
||||
1. Channel bots should receive mode +s and be in the Chanserv sop list.
|
||||
1. Channel moderators should receive mode +o and be in the ChanServ aop list.
|
||||
1. Channel moderators in training should receive mode +h and be in the ChanServ hop list.
|
||||
1. Channels should receive descriptive topics, URLs, and descriptions in their ChanServ settings so that users can learn more about the project.
|
||||
|
||||
## IRC Operation
|
||||
IRC Operation is a complicated issue for even small networks. Various sites offer some assistance <ref name=irchelp>[http://www.irchelp.org/ircd/ircopguide.html IRCHelp.org, accessed 2019/04/24]</ref> but all IRC operators or "IRCops" should be familiar with the KILL, REHASH, RELOAD, DIE, TRACE, STATS, LINKS, and HTM commands, as well as their individual module config. Refer to your IRCd's documentation for the syntax on these.
|
19
Services/IRC.d/IRC_Discord_Bridge.md
Normal file
19
Services/IRC.d/IRC_Discord_Bridge.md
Normal file
@ -0,0 +1,19 @@
|
||||
We maintain some [https://discordapp.com Discord] services for users that are less tech-savvy or want to work primarily with Web front-ends.
|
||||
|
||||
# Bridge
|
||||
We bridge some specific IRC channels to Discord for convenience. We will not create arbitrary channel mirroring -- we encourage users to focus on IRC for user-driven channels.
|
||||
1. lobby mirrors to IRC #lobby and is where all new users are connected.
|
||||
1. tech mirrors to IRC #tech for projects.
|
||||
1. martialart mirrors to IRC #martialarts in support of our [[Martial Arts]] class.
|
||||
|
||||
We use the [https://github.com/reactiflux/discord-irc.git reactiflux discord-irc bridge] to set this up.
|
||||
|
||||
# Werewolf
|
||||
We run an instance of [https://github.com/belguawhale/Discord-Werewolf.git belugawhale's Discord-Werewolf bot] for playing text games in the #textgames channel.
|
||||
|
||||
# Voice Channels
|
||||
We do have a couple voice channels set up.
|
||||
1. General is for anyone and everyone to talk.
|
||||
1. Table Talk is for folks playing remote games to chat together.
|
||||
1. Raids is dedicated to our Raid Team role, primarily for our [[Games#MMO.27s|SWTOR]] raids on the Empire faction.
|
||||
1. There is also a voice channel for admins to deal with critical network decisions and incidents.
|
53
Services/IRC.md
Normal file
53
Services/IRC.md
Normal file
@ -0,0 +1,53 @@
|
||||
IRC is a chat system used by members of the AniNIX network. See [[IRC#Available Clients|Available Clients]] for access methods.
|
||||
|
||||
# Etymology
|
||||
[https://en.wikipedia.org/wiki/IRC IRC] stands for Internet Relay Chat -- it is a method of text-based communication across the network via various servers. IRC has long been the self-hosted communication medium of choice for hackers, developers, and the fringe -- though overall adoption has dropped a bit with the rise of other social media, networks like [https://freenode.org Freenode] are growing. IRC<ref name=ircgrow>https://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/</ref> is moving to the hacker niche, and we follow along.
|
||||
|
||||
# Relevant Files and Software
|
||||
The configuration for the IRC service is divided into two parts -- the daemon and services.
|
||||
## InspIRCd
|
||||
The IRC daemon is powered by [https://inspircd.org/ InspIRCd 2][[Category:InspIRCd]]. Relevant configuration is in [file:///etc/inspircd/inspircd.conf the conf file] and it logs to [file:///var/log/inspircd/startup.log startup.log].
|
||||
## Anope
|
||||
The services component is supplied by [https://www.anope.org/ Anope 2][[Category:Anope]]. Relevant configuration is in [file:///etc/anope/services.conf the services.conf] and it logs to the [file:///var/log/anope/ the anope log].
|
||||
|
||||
Anope also takes backups of [file:///var/db/anope/anope.db the anope database] to the backups folder in the same location. [[Category:TODO]]<!--This should be backed up with Wiki-->
|
||||
|
||||
<b>Caution:</b> Anope with version 2.0.3 has some issues with gcc6. If you start encountering segmentation faults with Anope, sign in to [[irc://anope.org#anope The Anope support IRC]]. Script a run of "sudo -u ircd gdb /usr/bin/services core". Enter "r <your flags>" and when it crashes run "bt full". Quit out of everything and pastebin the file. Provide this to the support staff.
|
||||
|
||||
Anope Services' NickServ authentication can be linked to [[Sora|AniNIX::Sora]] for unified credentials.[[Category:LDAP]]
|
||||
|
||||
### Service entities
|
||||
The following entities can be messaged personally (PM'ed) for help with "/msg <entity> help
|
||||
|
||||
|
||||
[[Category:Public_Service]]
|
||||
* NickServ will manage IRC nicknames.
|
||||
* HostServ will manage IRC virtual hosts, to mask IP's.
|
||||
* ChanServ will manage IRC channels -- new channels can be registered on the network here.
|
||||
* MemoServ will manage IRC memos (short text-message-like messages between users).
|
||||
|
||||
# Available Clients
|
||||
You will need to use your own client. All IRC clients will connect to the service by providing the following information:
|
||||
* Host: aninix.net
|
||||
* Port: 6697
|
||||
* The client should accept invalid certificates.
|
||||
* The client should automatically join the #lobby channel.
|
||||
* The client should provide a nickname and NickServ password that the user intends to use.
|
||||
|
||||
### Clients by OS
|
||||
Some example clients can be found here.
|
||||
* Linux hosts are strongly recommended to use [https://wiki.archlinux.org/index.php/Weechat weechat] inside [https://wiki.archlinux.org/index.php/Tmux tmux] with the [https://weechat.org/themes/source/crym.theme.html/ crym theme], though a Hexchat version is also available.
|
||||
* Windows hosts can connect to this service using [https://hexchat.github.io/ HexChat].
|
||||
* Mac hosts can use [http://colloquy.info/downloads.html Colloquy].
|
||||
* Android hosts can use [http://www.duckspike.net/andchat/ Andchat].
|
||||
* iOS devices should use [http://colloquy.info/downloads.html Colloquy's mobile version].
|
||||
|
||||
# Equivalents or Competition
|
||||
Rivals to IRC include other IRC networks like [http://freenode.net Freenode], mail services like [https://inbox.google.com Google Inbox], and other chat systems like Slack, Microsoft Teams, Discord, Snapchat, WhatsApp, etc. We use Discord to provide new users with a Web-only bridge to the IRC network at https://aninix.net/irc/ -- [[IRC/Discord Bridge|documentation for our Discord hosting]] is also available..
|
||||
|
||||
# Additional Reference
|
||||
{{:IRC/Commands and Modes}}
|
||||
|
||||
### Helpful Reading
|
||||
|
||||
# Additional Reference
|
18
Services/SSH.md
Normal file
18
Services/SSH.md
Normal file
@ -0,0 +1,18 @@
|
||||
Remote access is important in the AniNIX, and so we support the use of the [https://wiki.archlinux.org/index.php/Secure_Shell OpenSSH] protocol via [[ShadowArch]] to supporting hosts.
|
||||
|
||||
# Etymology
|
||||
SSH is named for the protocol on which it's built.
|
||||
|
||||
# Relevant Files and Software
|
||||
Most of this service's configuration lives in [file:///etc/ssh/sshd_config sshd_config]. This includes match statements on what groups are allowed to connect, allowed protocols, and somewhat importantly the ForceCommand directives that hold certain users captive to specific operations.
|
||||
|
||||
VNC and X11 forwarding can be used over SSH to allow graphical clients. X11 forwarding without SSH compression is generally slower. To allow VNC, log in over SSH and forward remote port 5901 to localhost port 5901. Start the VNC server on the remote, and use a VNC viewer like tightVNC portable to view the remote desktop.
|
||||
|
||||
# Available Clients
|
||||
* Windows users should use [http://www.putty.org/ PuTTY]. The AniNIX considers this important enough that a copy of PuTTY is mirrored in [https://aninix.net/wolfpack/ WolfPack].[[Category:CachedClient]]
|
||||
* Mac has a native client in their Terminal application.
|
||||
* Linux users can install [https://wiki.archlinux.org/index.php/Secure_Shell openssh].
|
||||
* Android users can use [https://serverauditor.com/ Server Auditor].
|
||||
}}
|
||||
[[Category:Public_Service]]
|
||||
[[Category:LDAP]]
|
17
Services/Sharingan.md
Normal file
17
Services/Sharingan.md
Normal file
@ -0,0 +1,17 @@
|
||||
Sharingan is the monitoring solution for the AniNIX, replacing legacy, homebrew Heartbeat.
|
||||
|
||||
# Etymology
|
||||
Sharingan is named after the mythical technique from the Naruto anime series. Sharingan confers deep insight abilities to its user, and our implementation of it will do the same for our administrators' domains.
|
||||
|
||||
We are considering a Greylog or rsyslog service alongside Nagios[[Category:Nagios]] to implement a security best-practice.[[Category:TODO]]
|
||||
|
||||
# Relevant Files and Software
|
||||
Sharingan maintains all of its configuration in [file:///etc/nagios/ one directory]. You can validate the configuration there with the following.
|
||||
<pre> nagios -t /etc/nagios/nagios.cfg</pre>
|
||||
|
||||
Sharingan can be installed from the [https://aninix.net/foundation/ConfigPackages ConfigPackages]' Sharingan Makefile. Clients will communicate over SSH, so there is a statement to make a nagios user ("make nagiosuser").
|
||||
|
||||
# Available Clients=See [[WebServer#Available Clients|AniNIX::Webserver's client list]].
|
||||
|
||||
# Equivalents or Competition=Various monitoring SaaS vendors are available, including one that Nagios sells.
|
||||
}}
|
22
Services/Singularity.md
Normal file
22
Services/Singularity.md
Normal file
@ -0,0 +1,22 @@
|
||||
Singularity is the AniNIX's news aggregator -- you can access its [https://aninix.net/singularity main page here].
|
||||
|
||||
# Etymology
|
||||
The Singularity is named for [https://en.wikipedia.org/wiki/Black_hole gravitational singularities]. As it is a pull service, it pulls news into itself.
|
||||
|
||||
<b>Note:</b> It's not to be confused with the [https://en.wikipedia.org/wiki/Technological_singularity technological singularity]. This service has no AI presently.
|
||||
|
||||
# Relevant Files and Software
|
||||
Most files will be installed with the [https://www.archlinux.org/packages/community/any/tt-rss/ tt-rss] package from ArchLinux. You can then link /usr/share/webapps/tt-rss to your [[WebServer]] root.
|
||||
|
||||
# Available Clients
|
||||
Singularity has a [[WebServer#Available Clients|web interface]] available, and there is an app in the [https://play.google.com/store/apps/details?id=org.ttrssreader Google Play Store] for [[Tricorder|Android devices]] and one in the iOS store as well.
|
||||
|
||||
# Equivalents or Competition
|
||||
Equivalents are included in some browers, like Firefox and Seamonkey. Online, [http://feedly.com Feedly] and other RSS aggregators allow subscribing to feeds.
|
||||
|
||||
# Additional Reference
|
||||
Singularity can be joined to the [[Sora|AniNIX::Sora]] domain for unified authentication.
|
||||
}}
|
||||
|
||||
[[Category:Public_Service]]
|
||||
[[Category:LDAP]]
|
134
Services/Sora.md
Normal file
134
Services/Sora.md
Normal file
@ -0,0 +1,134 @@
|
||||
Sora is the [https://en.wikipedia.org/wiki/LDAP LDAP]-enabled central crendential store of the AniNIX -- end users will have accounts here.
|
||||
|
||||
# Etymology=Sora was the name of a pivotal character in the Kingdom of Hearts series. As Sora holds the "keys to the kingdom", the name fit.<!-- I've considered renaming this, but I'm kind of happy with it, even though I didn't follow the Kingdom of Hearts series. -->
|
||||
|
||||
# Relevant Files and Software
|
||||
Most of the configuration initially is handled by the [https://aninix.net/foundation/ConfigPackages ConfigPackages'] Sora Makefile.
|
||||
|
||||
We use [file:///etc/openldap/users.d a users.d] folder to hold the default user definitions. uidNumber should generally start from 10000 and the .ldif files should never be deleted to track the maximum uidNumber.
|
||||
|
||||
# Available Clients
|
||||
See [[:Category:LDAP]] for more information on the services that are clients of Sora.
|
||||
|
||||
# Equivalents or Competition
|
||||
Both [[:Category:Google|Google]] and Facebook offer distributed authentication systems. Google in particular is a good equivalent, as some of the services used by this network rely on its authentication for various products it provides internally.
|
||||
|
||||
The AniNIX is not presently set up or planning to do distributed authentication.
|
||||
}}
|
||||
# Authorizing Other Services by Sora
|
||||
## [[ShadowArch]] OS Authentication
|
||||
You will need nss-pam-ldap as package installed. You will need to edit /etc/pam.d/su, /etc/pam.d/su-l, /etc/pam.d/system-auth, and /etc/nslcd.conf to match [https://eng.ucmerced.edu/soe/computing/services/ssh-based-service/ldap-ssh-access this link] and [https://wiki.archlinux.org/index.php/LDAP_authentication the Arch Wiki].
|
||||
## [[Windows]] OS Authentication
|
||||
We recommend the [https://pgina.org/ pGina] package -- this is a very smooth client.
|
||||
## [[SSH]]
|
||||
Edit /etc/ssh/sshd_config to allow PasswordAuthentication and PAM. This assumes the OS authentication is set up.
|
||||
|
||||
We recommend adding a passwdchange OS group on the external-facing SSH host and set up a ForceCommand around /usr/bin/passwd for users in that group. This allows you to enable centralized password changes from outside the command line for subscribing clients and then disable password changes in individual services.
|
||||
## [[IRC|IRCServices]]
|
||||
You will need to enable m_ldap and m_ldap_authentication in [file:///etc/anope/modules.aninix.conf the modules conf file]. The modules conf has the necessary parameters waiting to be filled in. We recommend updating the search_filter to "(&(!(shadowLastChange=0))(&(uid=%account)(objectClass=%object_class)))". This will prevent users from using a password reset by an administrator.
|
||||
|
||||
When you enable LDAP for IRCServices, we would recommend disabling email changes in m_ldap_authentication and disabling account creation in the NickServ configuration. Do not disable registration in m_ldap_authentication. This ensures that account provisioning is done by LDAP and users can group as necessary. Moreover, disable password changes by removing the NickServ set/*pass directives.
|
||||
## [[Singularity]]
|
||||
You'll need to update your plugins line in [file:///usr/share/webapps/tt-rss/config.php the config file] and add some parameters. Note: you'll be removing the auth_internal module, but you'll have to add it at least once to promote an LDAP user to admin.
|
||||
|
||||
<pre>
|
||||
define('PLUGINS', 'auth_remote, note, updater, auth_ldap');
|
||||
define('LDAP_AUTH_SERVER_URI', 'ldap://localhost:389/');
|
||||
define('LDAP_AUTH_USETLS', FALSE); // Enable TLS Support for ldaps://
|
||||
define('LDAP_AUTH_ALLOW_UNTRUSTED_CERT', TRUE); // Allows untrusted certificate
|
||||
define('LDAP_AUTH_BINDDN', 'uid=binduser,ou=People,dc=aninix,dc=net');
|
||||
define('LDAP_AUTH_BINDPW', 'secret');
|
||||
define('LDAP_AUTH_BASEDN', 'ou=People,dc=aninix,dc=net');
|
||||
define('LDAP_AUTH_ANONYMOUSBEFOREBIND', FALSE);
|
||||
define('LDAP_AUTH_SEARCHFILTER', 'uid=???');
|
||||
</pre>
|
||||
## [[Wiki]]
|
||||
Wiki is the most complicated to add with its multiple domain support, but the following snippet can be modified for a single domain. You'll need to comment out the fourth line at least once after logging in an LDAP user to promote that user to administrator.
|
||||
|
||||
<pre>
|
||||
1. LDAP Modules
|
||||
require_once( "extensions/LdapAuthentication/LdapAuthentication.php" );
|
||||
require_once( "includes/AuthPlugin.php");
|
||||
$wgAuth = new LdapAuthenticationPlugin();
|
||||
|
||||
1. LDAP Debugging
|
||||
$wgLDAPDebug = 0;
|
||||
$wgDebugLogGroups["ldap"] = "$IP/debug.log" ;
|
||||
|
||||
1. LDAP Connection info
|
||||
$wgLDAPUseLocal = false;
|
||||
$wgLDAPDomainNames = array( 'aninix.net', );
|
||||
$wgLDAPServerNames = array( 'aninix.net' => 'localhost', );
|
||||
$wgLDAPEncryptionType = array( 'aninix.net' => 'clear',
|
||||
#'aninix.net' => 'tls',
|
||||
);
|
||||
1. $wgLDAPOptions = array( 'aninix.net' => array( LDAP_OPT_DEREF, 0 ), );
|
||||
$wgLDAPPort = array( 'aninix.net' => 389, );
|
||||
$wgLDAPProxyAgent = array( 'aninix.net' => 'uid=binduser,ou=People,dc=aninix,dc=net', );
|
||||
$wgLDAPProxyAgentPassword = array( 'aninix.net' => 'secret', );
|
||||
$wgLDAPSearchAttributes = array( 'aninix.net' => 'uid', );
|
||||
$wgLDAPBaseDNs = array( 'aninix.net' => 'dc=aninix,dc=net', );
|
||||
$wgLDAPGroupBaseDNs = array( 'aninix.net' => 'ou=Group,dc=aninix,dc=net', );
|
||||
$wgLDAPUserBaseDNs = array( 'aninix.net' => 'ou=People,dc=aninix,dc=net', );
|
||||
$wgLDAPAddLDAPUsers = array( 'aninix.net' => false, );
|
||||
$wgLDAPUpdateLDAP = array( 'aninix.net' => false, );
|
||||
$wgLDAPPreferences = array( 'aninix.net' => array( 'email' => 'mail','realname' => 'cn','nickname' => 'uid'), );
|
||||
|
||||
1. LDAP Access Only by Group Membership -- requires the memberOf overlay in Sora
|
||||
1. $wgLDAPGroupUseFullDN = array( "aninix.net"=>false );
|
||||
1. $wgLDAPGroupObjectclass = array( "aninix.net"=>"posixgroup" );
|
||||
1. $wgLDAPGroupAttribute = array( "aninix.net"=>"memberuid" );
|
||||
1. $wgLDAPGroupSearchNestedGroups = array( "aninix.net"=>false );
|
||||
1. $wgLDAPGroupNameAttribute = array( "aninix.net"=>"cn" );
|
||||
1. $wgLDAPRequiredGroups = array( "aninix.net"=>array("cn=wiki,ou=Group,dc=aninix,dc=net"));
|
||||
|
||||
1. Disable password changes.
|
||||
$wgHooks['UserLoginForm'][] = 'lfChangeLoginPage';
|
||||
function lfChangeLoginPage( &$template ) {
|
||||
$template->set('canreset',false); // removes default reset password link
|
||||
$template->set('resetlink',false);
|
||||
// Use the following line to show your own 'reset password' link above the login fields
|
||||
$template->set('link',"<a href='http://www.somedomain.org/lostpassword'>Forgot your password?</a>");
|
||||
return true;
|
||||
}
|
||||
// Disallow password reset on password reset page
|
||||
$wgHooks['UserLoginMailPassword'][] = 'MailPasswordIsAllowed';
|
||||
function MailPasswordIsAllowed ( $username, $error ) {
|
||||
$error = wfMsg( 'resetpass_forbidden' );
|
||||
|
||||
return false;
|
||||
}
|
||||
$wgHooks['PrefsPasswordAudit'][] = 'ChangePasswordIsAllowed';
|
||||
function ChangePasswordIsAllowed ( $user ) {
|
||||
throw new PasswordError( wfMsg( 'resetpass_forbidden' ));
|
||||
return true;
|
||||
}
|
||||
$wgHooks['GetPreferences'][] = 'RemovePasswordChangeLink';
|
||||
function RemovePasswordChangeLink ( $user, &$preferences ) {
|
||||
unset($preferences['password']);
|
||||
return true;
|
||||
}
|
||||
</pre>
|
||||
# Making Changes
|
||||
Ldapmodify will allow admins to change parts of Sora. Most user attributes can be updated like below.
|
||||
<pre>
|
||||
dn: uid=testuser,ou=People,dc=aninix,dc=net
|
||||
changetype: modify
|
||||
replace: mail
|
||||
mail: blar@test.local
|
||||
|
||||
</pre>
|
||||
|
||||
Some properties are more intrinsic to the user object and require special handling.
|
||||
<pre>
|
||||
dn: uid=testuser1,ou=People,dc=aninix,dc=net
|
||||
changetype: modrdn
|
||||
newrdn: uid=testuser2
|
||||
deleteoldrdn: 1
|
||||
modifying rdn of entry "uid=testuser2,ou=People,dc=aninix,dc=net"
|
||||
|
||||
</pre>
|
||||
|
||||
|
||||
[[Category:Security]]
|
||||
[[Category:LDAP]]
|
32
Services/Subscriptions.md
Normal file
32
Services/Subscriptions.md
Normal file
@ -0,0 +1,32 @@
|
||||
The AniNIX is not a complete solution -- the network recognizes that others do some projects in a superior manner with superior resources than are available directly to us. We subscribe to the following, at a total cost of $200 per year.
|
||||
|
||||
# Freehostia
|
||||
The [http://freehostia.com Freehostia] web hosting service also offers DNS services -- the AniNIX purchases public DNS listing and whois protection from this organization for $20 a year.
|
||||
|
||||
# Google
|
||||
Google provides a number of features to individual users for free. [[Category:Google]]
|
||||
* [https://keep.google.com Google Keep] provides an easy interface for nonpublic (as opposed to private) notes. It is browser- and mobile-accessible.
|
||||
* [https://maps.google.com Google Maps] provides a browser- and mobile accessible means of accessing maps and charts of the Earth's surface including semistatic satellite and 3D imagery.
|
||||
* [https://inbox.google.com Google Inbox] provides a browser- and mobile accessible email service.
|
||||
* [https://drive.google.com Google Drive] provides a browser- and mobile-accessible file upload and collaboration service.
|
||||
* [https://calendar.google.com Google Calendar] provides a browser- and mobile-accessible calendar.
|
||||
* [https://youtube.com YouTube] provides a subscription mechanism for user-uploaded content from around the world.
|
||||
* [[:Category:Mobile|Android]] devices in the AniNIX also benefit from being able to be tracked, locked, and remotely erased by their owning user via the [https://www.google.com/android/devicemanager Device Manager] service.
|
||||
|
||||
# Gutenberg Project
|
||||
The [https://www.gutenberg.org/ Gutenberg project] is a free reading library that augments Yggdrasil's digital library.
|
||||
|
||||
# Netflix
|
||||
[[Yggdrasil|AniNIX::Yggdrasil]] cannot store all material available. Netflix offers a quick and accessible streaming service for content that has not been archived in our own storage, at low cost of $10 a month for two screens.
|
||||
|
||||
# Emby
|
||||
> See [[:Category:Emby]] for subscription details.
|
||||
|
||||
# Pushbullet
|
||||
The [[Tricorder|AniNIX::Tricorder]] uses a Pushbullet service for $40 a year, offering remote access to SMS messages and notifications on mobile devices.
|
||||
|
||||
# TED
|
||||
The AniNIX monitors [[https://ted.com/ TED]] for new lectures on technology, entertainment, and design.
|
||||
|
||||
[[Category:Provider]]
|
||||
[[Category:Service]]
|
25
Services/VirusScan.md
Normal file
25
Services/VirusScan.md
Normal file
@ -0,0 +1,25 @@
|
||||
Malware is everywhere -- deployed by email, botcrawlers, script injection, physical intrusion, and many other vectors. Hosts in the AniNIX deploy the VirusScan service to protect themselves.
|
||||
|
||||
# Etymology
|
||||
The name comes from the function. [[Category:TODO]]
|
||||
|
||||
# Relevant Files and Software
|
||||
### Linux
|
||||
Linux hosts use the [https://wiki.archlinux.org/index.php/ClamAV ClamAV] package to scan for viruses. The AniNIX has a [file:///root/bin/vscan script] to execute the clamscan executable across all files, logging to [file:///var/log/clamscan.log log file] and reported via email to admins.
|
||||
|
||||
Crontab entries regularly execute the vscan and freshclam executables to scan the system and update the virus definitions daily.
|
||||
[[Category:ClamAV]]
|
||||
### Windows and Android
|
||||
Windows and Android hosts will use the [https://avast.com Avast] software package to conduct scans. There are no configuration files to be manipulated directly.
|
||||
[[Category:Avast]]
|
||||
|
||||
# Available Clients
|
||||
There are no clients for this service.
|
||||
|
||||
# Additional Reference
|
||||
## Hyper-V
|
||||
Hyper-V hosts that must run antivirus should make sure to [https://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx exclude these locations] to prevent guest disk errors as described in [[RCAs#Windows_Virtual_Disk_Failure]]. This includes both the host and any fileshares in use by other systems.
|
||||
|
||||
}}
|
||||
[[Category:Internal_Service]]
|
||||
[[Category:Security]]
|
31
Services/WebServer.md
Normal file
31
Services/WebServer.md
Normal file
@ -0,0 +1,31 @@
|
||||
Having some information be publicly accessible is useful to the network -- it's how we can be available to new people. Because HTTPS is the protocol of choice today, the WebServer is our vector.
|
||||
|
||||
# Etymology
|
||||
The WebServer serves content on the Web -- its name is simple to match the function.
|
||||
|
||||
# Relevant Files and Software
|
||||
Configuration files live in [file:///etc/lighttpd/lighttpd.conf lighttpd.conf], including ciphersuites, URI redirection, and pathing. It can be validated with the following.
|
||||
<pre>lighttpd -t -f /etc/lighttpd/lighttpd.conf</pre>
|
||||
|
||||
Most notably, our lighttpd.conf is set to set specific headers to prevent XSS vulnerabilities. We allow the plaintext listener for a better user experience, but we restrict scripts and style resources from loading from plaintext links via Content-Security-Policy. Our X-Frame options are also set to be restrictive against XSS vulnerabilities. We pin the [[Category:SSL|Let's Encrypt]] sha-256 public key signature, and require strict transport security.
|
||||
|
||||
Data files live in [file:///srv/http/ the http directory]. Each domain is virtually hosted by the AniNIX and pathing is set up in configuration. Sites in the WebServer are designed to be as sparse and lightweight as possible for rapidly disseminating information; this comes at a cost of beauty.
|
||||
|
||||
The WebServer uses six PHP child processes to handle the processing of pages. Both the WebServer and [[Wiki]] are built on PHP engines to reduce code sprawl and edit times. We will install a custom php.ini to handle things like disabling expose_php and configuring open_basedir.
|
||||
|
||||
**Please note:** We offer a redirect on www.aninix.net and http://aninix.net:80/ only as a legacy convenience as browsers do not yet support 443 by default -- no data is transmitted on these. When the webhosting community acknowledges the death of the empty www. subdomain and the necessity of encryption, we will drop these. However, for usability, we include them for now.
|
||||
|
||||
# Available Clients
|
||||
* Windows users should use [http://google.com/chrome/browser/desktop/ Chrome] or Firefox. A copy of Chrome is stored in [https://aninix.net/wolfpack WolfPack].
|
||||
* Privacy-conscious users may be interested in [http://www.seamonkey-project.org/ Seamonkey], also stored in WolfPack. This browser includes mail and IRC clients and can be installed on a [[Holocron|flash drive]]. It can be set to silently purge privacy information on closing, and it is lighter on the OS.
|
||||
* [[ShadowArch]] users should use Seamonkey; chromium can be used to support custom Chrome extensions and bleeding-edge services, like Pushbullet or Netflix.
|
||||
[[Category:CachedClient]]
|
||||
* Mac users should use Safari or Chrome.
|
||||
* Mobile users should use the built-in browser.
|
||||
|
||||
# Equivalents or Competition
|
||||
Hosting services like [https://godaddy.com GoDaddy] and [http://freehostia.com/ FreeHostia] will provide hosting services for web pages. Content management can be done with systems like WordPress.
|
||||
}}
|
||||
|
||||
[[Category:Public_Service]]
|
||||
[[Category:SSL]]
|
58
Services/Yggdrasil.md
Normal file
58
Services/Yggdrasil.md
Normal file
@ -0,0 +1,58 @@
|
||||
The AniNIX aims to share information. Yggdrasil holds the many worlds of information available. See [[Yggdrasil#Available Clients|Available Clients]] below for ways to access the system.
|
||||
|
||||
# Etymology
|
||||
The most commonly accepted etymology of the name is ygg "terrible" + drasil "steed". While the name means the "terrible steed", it is usually taken to mean the "steed of the terrible one", with Yggr the epithet of the god Odin. In other words, Odin's horse, referring to the nine nights he is said to have spent hanging from the tree, or "riding the gallows", in order to acquire knowledge of the runic alphabet.
|
||||
|
||||
The gallows are sometimes described in Old Norse poetry as the "horse of the hanged." In the case of "terrible steed", the association with Odin may be secondary, and any number of riders possible. A third interpretation, with etymological difficulties, is "yew-column", associating the tree with the Eihwaz rune.
|
||||
|
||||
Fjölsvinnsmál, a poem in the Poetic Edda, refers to the World Tree as Mimameid (Old Norse: Mímameiðr, "Mímir's tree" ). The tree is also probably identical to Laerad (Old Norse: Læraðr) a tree whose leaves and branches reach down to the roof of Valhalla and provide food for the goat Heidrun (Old Norse: Heiðrún) and the stag Eikthyrnir (Old Norse: Eikþyrnir).
|
||||
|
||||
## The Nine Worlds
|
||||
The Yggdrasil tree is home to the Nine Worlds in Norse Cosmology. The worlds are:
|
||||
In the north: Niflheim
|
||||
In the east: Jotunheim
|
||||
In the south: Musspelheim
|
||||
In the west: Vanaheim
|
||||
In the center: Midgard
|
||||
Above: Alfheim and Asgard
|
||||
Below: Svartalfheim and Helheim
|
||||
|
||||
## Residents
|
||||
The World Tree is inhabited by several animals, the Nίðhӧggr, pet dragon of the goddess Hel which chews the roots of the tree which bind it, Veðrfӧlnir the rooster, who will crow when Ragnarok occurs, Ratatӧsk the squirrel, who carries messages of hate between the eagle and the Nίðhӧggr. This eagle, who is not named, is said to have knowledge of many things, and on its head sits Veðrfӧlnir. The significance of Veðrfӧlnir is unclear but John Lindow suggests that it may represent a higher faculty of wisdom, possibly sent out to acquire knowledge in a similar manner as Odin's ravens Hugin and Munin.
|
||||
|
||||
The original Norn was undoubtedly Urd, a word which can be translated to mean "Fate". The Well of Urd, which was situated at the base of the great cosmic tree Yggdrasil, is named after this Norn. The two additional Norns that are known by name are Verdandi ("Present" [or "Necessity" in some versions]) and Skuld ("Future" [or "Being" in some versions]). All three Norns live at the Well of Urd in Asgard. According to Norse mythology, nothing lasts forever, and even the great Yggdrasil has been said to decay one day. The Norns try to stop or slow this process by pouring mud and water from the Well of Urd over its branches. The magical liquid stops the decaying process for a short time.
|
||||
|
||||
## Relevance to the Service
|
||||
|
||||
Yggdrasil is a knowledge repository for the AniNIX -- it literally "holds the worlds" for the network's data content.
|
||||
|
||||
|
||||
# Relevant Files and Software
|
||||
All configuration is cached inside the service -- we log to [file:///var/lib/emby/logs Emby's logs directory] and data lives in [file:///var/lib/emby /var/lib/emby]. You can build it using the [https://aninix.net/foundation/ConfigPackages ConfigPackages], which will handle the initial directory installation along with an emby-server service.
|
||||
|
||||
To keep a consistent color scheme, we add the following under the Emby Server Dashboard > Advanced > Branding. This does not help mobile, but it does make a significant help to computer use.
|
||||
<pre>
|
||||
/* https://benzuser.github.io/Emby-Web-Dark-Themes-CSS/ */
|
||||
@import url('https://rawgit.com/BenZuser/Emby-Web-Dark-Themes-CSS/master/RED/theme.css');
|
||||
</pre>
|
||||
|
||||
LDAP in Emby world is controlled by a dotnet plugin. Bind DN, search filters, and initial user setup are controlled within the plugin from the server admin panel; the plugin can be pulled from the plugin catalog inside Emby. Usage of it is dependent on an Emby premiere membership -- failure to have such will result in "System.Exception: Emby Premiere required for LDAP" messages in the logs. However, this can sometimes be a false positive if preceded by lines of "Error Plugin: Error checking registration status of ldapfeature" -- the latter will be caused by a [https://emby.media/community/index.php?/topic/59531-external-ssl-connections-crashing/page-3#entry589538 documented issue with dotnet core] that can be resolved by "sudo chmod a+r /etc/ssl/certs/*".
|
||||
|
||||
|
||||
# Available Clients
|
||||
### Music, Pictures, and Video
|
||||
* You can go to [https://aninix.net/yggdrasil the web-app] for a web-accessible view of the service.
|
||||
* Android users can use a specific [https://play.google.com/store/apps/details?id=com.mb.android app].
|
||||
### Books and Other Media
|
||||
* Windows users can use [https://winscp.net/eng/download.php WinSCP]. The AniNIX contains a cached copy of this in [https://aninix.net/wolfpack/ WolfPack].[[Category:CachedClient]]
|
||||
* Mac users have a native client.
|
||||
* Linux users should install the openssh client -- see [[SSH#Available clients]] for details.
|
||||
* Android should use [https://play.google.com/store/apps/details?id=turbo.client Turbo Client].
|
||||
|
||||
# Equivalents or Competition
|
||||
Rivals include [https://pinterest.com Pinterest], [https://soundcloud.com Soundcloud], [https://netflix.com NetFlix], [https://smile.amazon.com Amazon Kindle], [https://play.google.com Google Play], and [https://hulu.com Hulu].
|
||||
}}
|
||||
[[Category:Public_Service]]
|
||||
[[Category:SSL]]
|
||||
[[Category:Emby]]
|
||||
[[Category:LDAP]]
|
Loading…
Reference in New Issue
Block a user