FastLizard4.org Shell Server Acceptable Use Policy

   ___                 __    ___                                  __  __ __
 /'___\               /\ \__/\_ \    __                          /\ \/\ \\ \
/\ \__/   __      ____\ \ ,_\//\ \  /\_\  ____      __     _ __  \_\ \ \ \\ \
\ \ ,__\/'__`\   /',__\\ \ \/ \ \ \ \/\ \/\_ ,`\  /'__`\  /\`'__\/'_` \ \ \\ \_
 \ \ \_/\ \L\.\_/\__, `\\ \ \_ \_\ \_\ \ \/_/  /_/\ \L\.\_\ \ \//\ \L\ \ \__ ,__\
  \ \_\\ \__/.\_\/\____/ \ \__\/\____\\ \_\/\____\ \__/.\_\\ \_\\ \___,_\/_/\_\_/
   \/_/ \/__/\/_/\/___/   \/__/\/____/ \/_/\/____/\/__/\/_/ \/_/ \/__,_ /  \/_/
                                                    / __`\/\`'__\/'_ `\
                                                 __/\ \L\ \ \ \//\ \L\ \
                                                /\_\ \____/\ \_\\ \____ \
                                                \/_/\/___/  \/_/ \/___L\ \
                                                                   /\____/
                                                                   \_/__/

 FASTLIZARD4.ORG SHELL SERVERS
--== ACCEPTABLE USE POLICY ==--

Section 1 - Regarding Common Sense

Common sense is important. Common sense is what says "maybe launching a distributed denial-of-service attack against the United States Government is a bad idea and I shouldn't use a fastlizard4.org server to do it". Or, more subtly, "maybe hosting viruses from FastLizard4's server wouldn't be appreciated". Please, please, please - almost any question you have about this AUP can be answered with common sense. Don't do anything stupid or illegal, and you will almost certainly be fine. However, there are things that need to be spelled out, so read on....

Section 2 - Scope

This Acceptable Use Policy governs your use of resources that involve shell access to the fastlizard4.org server network. This includes SSH access itself, access to MySQL databases, personal web space or, if provided, web hosting (personal web space is served as http://fastlizard4.org/~username/ and is provided by default; web hosting requires extra configuration by the system administrators and requires the user to provide their own domain name). Summed up, if you have to SSH into a fastlizard4.org server to use it, then it is governed by this AUP.

Section 3 - Service is At Will

Whether or not you are paying for access to fastlizard4.org resources, you have the right to terminate your service at any time by contacting a server owner. If you are paying for service, then you will be refunded a pro-rated amount based on how much service you have used for the given billing period. E.g., if you pay for service monthly and you have already paid for a month but cancel your service 12 days in to the month, you will receive a refund for the 19 or however many days in the month you didn't use. Likewise, however, FastLizard4 has the right to terminate your service completely at any time for any reason. If your service was terminated for reasons of abuse and you have been warned in the matter, you may not receive a pro-rated refund for service used. Server owners in addition have the right to remove you from their own servers at will. Server administrators may recommend that service be terminated for those abusing the services. Server owners and administrators have the right to ban users from the server(s) they administer, a ban being a temporary denial of a user to access their resources on a fastlizard4.org server. In cases of a ban, your password and keys will be invalidated so you are unable to log in by SSH, your home directory moved so that it may not serve anything (e.g., user webspace), and all processes running under your username killed. In case of service termination, your user account will be deleted and your home directory, MySQL databases, and all other user data deleted. A backup of your home directory, MySQL databases, and other user data will be provided unless it is deemed that your account served no useful purpose - i.e., it was intended for abuse only - in which case no backup will be provided.

If at all possible, a reasonable effort will be made to provide advance notice of access termination or a ban.

Section 4 - Your Responsibilities

Section 4.1 - Mandates

1. You are responsible for maintaining your account and services. If you uploaded it to the server, you're responsible for it.
2. You are responsible for maintaining the security of your account. Use strong passwords and, optionally, SSH keypairs for authentication. Optionally but highly recommend, use two-factor authentication to provide extra security, regardless of whether you use passwords or keys to log in.
3. In the event that your account is compromised, you must notify a system administrator immediately.
4. You are prohibited from sharing your SSH login password and/or keys with anyone, nor may you share your MySQL username and password, if given to you, with anyone. You may allow others to use your shell account, provided that you don't share your password or login key, and with the understanding that you, as the account holder, are responsible for all activities of those you share your account with.
5. You are responsible for remembering your password. Please be advised that six successive failed password attempts will result in your IP address being banned from attempting to log in through SSH by DenyHosts, and you'll have to contact a server owner to restore your access.

Section 4.2 - User Emergency Contact Information

Note: This section was written and goes into effect on 6 October 2014 UTC.

Section 4.2.1 - What and Why

New users, i.e., users who are having their FastLizard4.org shell server accounts created on or after the effective date of Section 4.2 of this AUP, are strongly advised to provide the server administrator creating their account their emergency contact information. Server administrators will use this information to contact you should software, services, or other entities under your control on the server begin acting in a way contrary to smooth server operation (for specific examples, see Section 5 of this AUP). Server administrators will ask you, during the account creation process, for this information. You may choose to decline to provide emergency contact information, though you must make this explicit to the server administrator creating your account (for more information on declining to provide emergency contact information, and the consequences this may carry, please see Section 4.2.3 of this AUP).

The following is a list of examples of acceptable forms of emergency contact information. This is not an exhaustive list; if you would like to use a method not listed here, please ask the server owner if it is acceptable.

• Apple iMessage (phone number or email address).
• Text message (SMS to a phone number, United States or Google Voice only).
  • International users wanting to use SMS as their emergency contact method should ask the server owner if their country of residence is supported.
• Email (the user must promise that the email address provided is checked frequently, at the very least once every two or three hours, and should provide an alternate emergency contact method for more urgent situations).
• Instant messaging, such as Skype text chat, AIM, Windows Live Messenger, and Google Talk, assuming that the user monitors their instant messaging accounts.
• Twitter direct messaging, provided that the user reads incoming direct messages in a timely manner.

IRC is, notably, not an acceptable emergency contact method.

Existing shell server users, i.e., users whose accounts were created before the effective date of this section, are strongly advised to provide their server's/servers' owner(s) with emergency contact information. Users who do not do so will be considered to have declined providing emergency contact information and are subject to the consequences listed in Section 4.2.3 of this AUP.

All users must keep their emergency contact information up to date by contacting a server owner when there is a change. Users may request that their emergency contact information be removed from shell server records, though doing so will be considered as the user declining to provide their emergency contact information, and as such the user will be subject to the consequences listed in Section 4.2.3 of this AUP. Any user who has declined to provide emergency contact information may provide such contact information at any time by contacting a server administrator or server owner.

Users' emergency contact information is shared between all servers. Updating it with one server's owner will update it on all servers, not just those owned by said server owner.

Section 4.2.2 - Server Administrators' Restrictions on Use of Users' Emergency Contact Information

Server administrators may only compile users' emergency contact information for the purpose of emergency contact. The information may not be used in any other manner, and the location in which this information is compiled must be secured from use or viewing by non-server-administrators. If a user requests that their emergency contact information be stricken, it must be struck immediately from the centralized shell server records as well as any personal records maintained by server administrators. Users' emergency contact information may not be shared with anyone who is not a server owner or administrator. Users' emergency contact information will not be shared with any law enforcement, governmental, or other agency without a valid court order, subpoena, or warrant, and in these cases, the user will be notified that their information has been likewise shared.

Section 4.2.3 - Declining To Provide Emergency Contact Information

Users may freely decline to provide their emergency contact information, and no questions will be asked if they do so. However, users should be aware that, by necessity, declining emergency contact information carries some consequences. Not providing emergency contact information may make it more difficult for a server administrator to contact you for urgent matters, which may result in swifter action being taken to protect the server than if emergency contact information were available. For example, if a user's process is consuming too much system resources, a system administrator will first attempt to contact the user by their emergency contact information to have them rectify the situation. However, if emergency contact information is not available for that user, the system administrator may choose to kill the process immediately to protect the system, then send the user an email to explain what happened.

Of course, even if emergency contact information is provided by the user, the lack of a timely response may also result in a system administrator taking action to protect the system before getting in contact with the user. It is therefore important to not only provide emergency contact information, but to also monitor your emergency contact channel and respond swiftly if a shell server administrator tries to contact you!

Section 4.3 - LizardNet Email

All FastLizard4.org Shell Server users gain access to LizardMail. The technical details are described at the aforelinked page. LizardMail is not valid as an emergency contact route, since it depends on LizardNet services running smoothly. That being said, LizardMail will be used to distribute service announcements such as downtime notifications and AUP update notifications, and as such all users are expected to check their LizardMail accounts at least once per day. In addition, if a server administrator takes an action against something under your control, such as killing a misbehaving process running under your username, they will emails your LizardMail account explaining what happened. We are not responsible for issues caused by not checking your LizardMail account frequently!

Section 5 - Acceptable Conduct and Prohibited Usage

Section 5.1 - Interference with Services

Your activities on a fastlizard4.org server must not interfere with any other users' activities, and especially not with activities the owner of the server. In this respect, a server owner's activities have priority over any other users'. You also may not disrupt the network or any other systems connected to the server you are using.

Section 5.2 - Server Applications and Daemons

A user may run any software that actively listens for incoming connections, even from non-localhost (localhost being defined as 127.0.0.1 or ::1) hosts, provided that they follow the following rules:

• Ports 0 through 1023 (TCP and UDP) are reserved for the server owner, unconditionally.
• The following ports, TCP and UDP, are also reserved for the server owners and administrators and may not be used for listening by general users (without prior permission): 1701, 1723, 3306, 4500, 6660 - 6669, 6697, 7000 - 7009, 8000 - 8002, 8080, 9999, 10011, 21025, 30033, 25560 - 25579
• You may "register" your port by asking a server owner or server administrator, who will assign you the port(s) of your choice or (a) port(s) that are free if you do not have any particular preference. Ports assigned to a user cannot be used by other users (users using ports assigned to other users will have their processes killed). Registered ports may be deregistered by the system administrator(s), but not without advance notice, and they may only be deregistered in cases of abuse, or if the system administrators or owners wish to themselves use the port.
  • The file portmap in the root directory of the server contains a list of current user/port assignments.
  • Registering ports is highly recommended if you plan on running an application that must listen on (a) port(s) for an extended time (like an IRC bouncer).
• You do not have to register ports or be assigned ports to listen on them. However, unassigned ports are offered on a first-come-first-serve basis, so if another user starts using an unregistered port you were listening on, you must yield to them. Additionally, system owners and administrators have priority on unregistered ports and may begin using them at will (thus blocking general users from using them).

Section 5.3 - Responsible Use of Resources

Please use resources (CPU time, RAM, swap, network I/O, disk, etc.) responsibly. Do not use programs that continuously excessively use these resources. If a program is consuming too much of a resource, a server administrator or owner may kill it and warn you. Intentional or continual over-consumption of resources may result in a ban. Remember, you aren't the only user on these systems.

If you plan on running a resource-intensive program (this includes ANYTHING written in Java!!), please ask the server owner(s)/server administrator(s) first to see if it's okay.

Section 5.4 - No Spam

Do not use fastlizard4.org servers to send spam, junk email, or unsolicited bulk email. In other words, don't send anyone an email unless they've somehow requested it, especially if it's the same email going to multiple people who haven't requested it. Do not forge email headers. If you wish to create a mailing list, speak to FastLizard4 about using LizardWiki's Mailman software.

Section 5.5 - Access to Unauthorized Services

Do not use your fastlizard4.org resources to access systems you are not authorized to access, or to exploit security vulnerabilities or bypass security measures in any systems. In addition, do not use your resources to subvert LizardWiki or any other services hosted on the fastlizard4.org network.

Section 5.6 - Illegal and Other Forbidden Activities

Do not perform any activities that are illegal in the United States or your country of residence. Do not host or store materials in violation of intellectual property or copyright laws. Do not use fastlizard4.org servers to store pornography. Do not use fastlizard4.org servers to host illegal materials including but not limited to pirated movies, pirated TV shows, pirated games, warez, viruses, or malware. Do not perform activities intended to harm or exploit fastlizard4.org servers or users.

Section 6 - Uptime

No guarantee is made about server uptime and/or availability of resources. Server owners will do their best to provide high uptime and consistent service, and must make reasonable effort to notify users before any planned downtime. No SLA is provided.

Section 7 - Logging

All SSH logins to fastlizard4.org servers are logged and monitored for abuse. Mail sent and received is also logged, though the contents of these emails are not monitored. Logged data includes IP addresses, and may include email addresses. Failed sudo attempts are logged and may result in a ban.

Section 8 - Disclaimer

YOU ARE PROVIDED SERVICE WITH NO WARRANTY, CLAIM OF MERCHANTABILITY, OR CLAIM OF FITNESS FOR A PARTICULAR PURPOSE. Service can be interrupted by factors beyond the control of server administrators and owners, and you the user by agreeing to this ALU also agree that you understand this. Server owners will not be responsible for data loss or other damages caused by such factors. For factors that are in the control of server owners, the most restitution you may seek is for service you have paid for, if anything. You are responsible for keeping backups of your own data, and again, you are solely responsible for maintaining services you operate through fastlizard4.org servers!

Section 9 - Updates to This Policy

This policy may be updated any time by FastLizard4. All servers' MOTDs, which are seen upon successful login, will display the UTC timestamp of the last change. All users are responsible for checking the timestamp and reading updates to the AUP. Continuing to use services after an AUP update will constitute your acceptance of the updated AUP.

Section 10 - Agreement to This Policy

By using fastlizard4.org shell server services, you agree to this policy in its entirety. If you do not agree to the policy, please take a backup of your data, delete all your data, and notify the server owner immediately to terminate your account. In addition, as mentioned in Section 9 above, continuing to use fastlizard4.org shell services after an AUP update constitutes agreement to the updated AUP.