Here are some general system policies that are followed on the halibut:
We try not to snoop on our users, but we sometimes have to in the course of system maintenance. Intruders are fair game for snooping, and whatever prodding strikes our fancy at the time. If you're doing something on our system that you're not supposed to make sure we don't find out about it, because we may feel obligated to act.
Account expiration is a hard thing to do on a free system. You can't stop giving us money, because you never gave us money to begin with. As such, we need to base it on something else. In our case, we use password expiration to flag unused accounts. Here's how it works: After setting up a new password, you have 120 days of use of that password. After 90 days with the same password, the system will start to warn you that your password is going to expire. These warnings occur on login (using telnet or secure shell), and by mail. If you still haven't changed your password after the full 120 days, the password becomes invalid. Logging in to any service other than telnet or secure shell after this period yields a failure. Telnet and secure shell force you to change your password. If you still don't change your password for another 30 days, your account is frozen. This means that you can no longer log in using any service. The only way of re-activating a frozen account is to contact the system administrators, and have them assign you a temporary password. 30 days after that, the account is considered abandoned. The account is then deleted.
Note: We are currently having difficulty with an interaction between sshd and PAM, which leads to sshd not prompting you to changed your password. As such, once your password expires, you will be unable to change it through secure shell. Please change your password before it expires.
We intermittently remove idle logins from the Halibut systems, and kill all associated processes. This is both for system performance and aesthetic reasons. Any login that is idle for more than an hour is fair game. If we find that users are artificially keeping their idle times low, we will react poorly. Idle logins associated with processes that take up too many system resources (such as mail readers accessing huge mail spools) are removed with prejudice, and serve to piss off the admins.
The backup status varies. It is best to assume currently that we do not have a backup of user data.
In the context of this policy, a 'user run daemon' is any process designed to run as the user while the user is not logged in. In the context of these policies, there are two main types of user daemon: Those that result in a new remote service, and those that do not.
User run daemons that result in a new remote service are discouraged. These increase the number of remote attack points, and decrease the security of the system as a whole. That being said, if you really want to run a daemon that results in a new remote service, talk to us. We'll probably allow it (particularly after a security audit and / or a chroot jail wrapper), we just won't like it. You should talk to us about it, though. We don't like stumbling onto such things during a security audit. We tend to over react.
User run daemons that do not result in a new remote service are allowed. It is important to note that if your daemon takes up too many system resources, we will kill it. If you continue to run it and it continues to consume too many system resources, we may react in a more decisive way.
User CGIs are currently allowed. This policy is subject to change, or at least further refinement.
chiba.halibut.com uses RBL filtering to decrease the amount of SPAM received. The following RBLs are consulted for each connecting host:
All domains that have a mx record pointing to chiba.halibut.com (a.k.a. mail01.halibut.com) also have these protections in place automatically.
If you want us to provide DNS services to you, it is important for you to realize that we don't use BIND (we use DJB DNS), and as such it is difficult for us to offer certain services. It is easiest for us to act as a primary server for DNS requests. We do not offer remote AXFRs from our site. Our local DNS zonefiles are not in the standard Bind format.
We can do some (basic) secondary services, including AXFRing domains periodically (currently every day). We ignore many of the SOA fields (all of them but the serial number and TTL, actually). If this is a problem, you may want to consider not hosting your DNS with us.