You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Robert Dinse <na...@eskimo.com> on 2019/03/11 00:06:59 UTC
guacd not starting on boot
I have guacd installed, built with the --with-systemd flag and it does
not install a systemd file but an initd file which systemd recognizes and
says it installs however, while systemctl start guacd works fine and
systemctl enable guacd indicates it did the right thing, it does not start
upon boot, I have to manually start it. Because some of the things it uses
are on NFS partitions, I suspect it's trying to start before NFS is up and
failing.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
Re: guacd not starting on boot
Posted by Robert Dinse <na...@eskimo.com>.
And it's open sourced, and while I don't know Java, I do know C, so if
it becomes important enough to me there is always that option.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Mon, 11 Mar 2019, Nick Couchman wrote:
> Date: Mon, 11 Mar 2019 09:10:46 -0400
> From: Nick Couchman <vn...@apache.org>
> Reply-To: user@guacamole.apache.org
> To: user@guacamole.apache.org
> Subject: Re: guacd not starting on boot
>
> On Mon, Mar 11, 2019 at 7:37 AM Robert Dinse <na...@eskimo.com> wrote:
>
>>
>> /var/run is a tempfs file system and recreated at each boot so
>> changing
>> the perms on it are gone on the next boot. As for the encryption key, lots
>> of things run as daemon, I don't want them all having access to the key.
>>
>
> Yes. I addressed both of these issues in my previous e-mail:
> - /var/run is managed by tmpfilesd on most systems where it is completely
> temporary and that also run systemd. So, you can put rules into
> /etc/tmpfiles.d that create these files for you.
> - You do not have to use the "daemon" user. It was a convenient default
> for the purposes of creating and distributing the systemd unit file, but
> you can run guacd under any user account that you like. Again, as already
> mentioned, I generally create a "guac" user account and run both Tomcat and
> guacd under that user account. This way I can 1) make sure neither guacd or
> Tomcat are running as root, and 2) that both have the necessary access to
> the files and folders under /etc/guacamole that define the configuration
> for Guacamole, including sensitive information like certificates/keys,
> database username/password, etc.
>
>
>>
>> At any rate, that's my suggestion for functionality.
>>
>
> Appreciated. You're welcome to file a feature request in JIRA for this and
> see where it goes. The point is, it isn't required to get where you want
> to go.
>
>
>>
>> I still have some other issues to work out but they're with my hosts
>> not with guacamole. I have sound working on debian and mint. Have not
>> been
>> able to get it to work on ubuntu yet nor on any redhat derived system, I
>> get
>> connection refused from the pulseaudio port on those machines even after
>> adding
>> the suggested configuration change to /etc/pulse/default.pa.
>>
>>
> RedHat has firewalld enabled and active by default, I believe, so it's
> possible that's blocking something. Not sure about Ubuntu.
>
> -Nick
>
Re: guacd not starting on boot
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Mar 11, 2019 at 7:37 AM Robert Dinse <na...@eskimo.com> wrote:
>
> /var/run is a tempfs file system and recreated at each boot so
> changing
> the perms on it are gone on the next boot. As for the encryption key, lots
> of things run as daemon, I don't want them all having access to the key.
>
Yes. I addressed both of these issues in my previous e-mail:
- /var/run is managed by tmpfilesd on most systems where it is completely
temporary and that also run systemd. So, you can put rules into
/etc/tmpfiles.d that create these files for you.
- You do not have to use the "daemon" user. It was a convenient default
for the purposes of creating and distributing the systemd unit file, but
you can run guacd under any user account that you like. Again, as already
mentioned, I generally create a "guac" user account and run both Tomcat and
guacd under that user account. This way I can 1) make sure neither guacd or
Tomcat are running as root, and 2) that both have the necessary access to
the files and folders under /etc/guacamole that define the configuration
for Guacamole, including sensitive information like certificates/keys,
database username/password, etc.
>
> At any rate, that's my suggestion for functionality.
>
Appreciated. You're welcome to file a feature request in JIRA for this and
see where it goes. The point is, it isn't required to get where you want
to go.
>
> I still have some other issues to work out but they're with my hosts
> not with guacamole. I have sound working on debian and mint. Have not
> been
> able to get it to work on ubuntu yet nor on any redhat derived system, I
> get
> connection refused from the pulseaudio port on those machines even after
> adding
> the suggested configuration change to /etc/pulse/default.pa.
>
>
RedHat has firewalld enabled and active by default, I believe, so it's
possible that's blocking something. Not sure about Ubuntu.
-Nick
Re: guacd not starting on boot
Posted by Robert Dinse <na...@eskimo.com>.
/var/run is a tempfs file system and recreated at each boot so changing
the perms on it are gone on the next boot. As for the encryption key, lots
of things run as daemon, I don't want them all having access to the key.
At any rate, that's my suggestion for functionality.
I still have some other issues to work out but they're with my hosts
not with guacamole. I have sound working on debian and mint. Have not been
able to get it to work on ubuntu yet nor on any redhat derived system, I get
connection refused from the pulseaudio port on those machines even after adding
the suggested configuration change to /etc/pulse/default.pa.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Mon, 11 Mar 2019, Nick Couchman wrote:
> Date: Mon, 11 Mar 2019 07:06:40 -0400
> From: Nick Couchman <vn...@apache.org>
> Reply-To: user@guacamole.apache.org
> To: user@guacamole.apache.org
> Subject: Re: guacd not starting on boot
>
> On Sun, Mar 10, 2019 at 11:04 PM Robert Dinse <na...@eskimo.com> wrote:
>
>>
>> Ok, rebuilt with the correct --with-systemd-dir=/lib/systemd/system
>> and
>> now I had more problems. Launched out of init.d it ran as root, launced
>> out
>> of systemd, the unit file it created has User=daemon so it runs as daemon.
>> Problem with that is only root has access to /var/run and to the
>> encryption key
>> file so I changed it back to root despite that being less secure.
>>
>
> Or you could change permissions on the files so that the daemon user has
> access to them. For the encryption key, this should be pretty
> straight-forward:
>
> chown daemon /path/to/encryption/key
>
> For /var/run, I'm not sure why the daemon user would need access to that
> directory? I suppose it could if you're adding "-p /var/run/guacd.pid" to
> the command line or specifying a PID file in the guacd configuration, but
> by default there are no requirements for this. Furthermore, with systemd
> in particular, I'm not sure that's there much value to having it generate a
> PID - system runs things in the foreground by default and manages tracking
> the PID of the daemon, so there's really not much you'd need the PID file
> for.
>
> If you do want that PID file in /var/run, for whatever reason, in most
> distributions that run systemd /var/run is managed by tmpfilesd, and can be
> configured by adding the appropriate file to /etc/tmpfiles.d with the files
> and/or directories and the required ownership and permissions.
>
>
>>
>> Lastly it still failed because it tried to start before /misc was
>> mounted
>> which is where the key file was so I modified the unit file line:
>>
>> After=network.target
>>
>> to:
>>
>> After=network.target misc.mount
>>
>> /misc is the file system where I have the encryption certs and keys.
>>
>> Now it starts properly after a reboot. Downside, as with when it ran
>> out of /etc/init.d, it is running as root which from a security perspective
>> is undesirable.
>>
>
> But, this is your choice, not a requirement - you've changed it from daemon
> to root to resolve other issues that should be resolved with either a chown
> (or ACLs) and proper configuration.
>
>
>>
>> What guacd should have is an item that goes into guacd.conf for user
>> and
>> group so it can start as root, write the pid file and read the necessary
>> cert and key files, and then switch to said user and group just like Apache
>> httpd and tomcat do.
>>
>
> httpd does this, Tomcat does not. Tomcat is started by the startup.sh
> script, and that script must be run under the account that you want running
> Tomcat. Tomcat does not implement user context switching at startup, and
> should (IMHO) *never* be started as root.
>
>
>>
>> Then it could be both secure and functional.
>>
>
> There may be some value to looking into doing this - having the initial
> user be root and then switch to another user - but please understand that
> it is not required to make guacd both "secure and functional" as it is
> implemented today. There is no reason at all that you cannot set
> permissions on all of the required items - GUACAMOLE_HOME (/etc/guacamole),
> encryption keys and certificates, and the necessary /var/run entries - to
> the user specified in either the init script or the systemd file (+
> tmpfiles.d) so that guacd runs under a non-root account. You don't have to
> use the daemon user if you don't want to - this was a convenient default
> for the systemd unit file when we added it - you can create a separate user
> for guacamole (I often use "guac") and change permissions to that user
> along with the systemd script, and you will be able to operate in both a
> "secure and functional" fashion.
>
> Furthermore, there are other methods you could use to protect guacd and the
> required files, like chroot jails or Docker containers. Docker is already
> available, and, while chroot jails are not implemented by default, the
> requirements for guacd are reasonably simple enough that it should be
> doable with minimal effort.
>
> The point here is that, while there may be some value to having guacd start
> under root and switch internally, there's no reason you have to do this in
> order to make guacd function and function securely.
>
> -Nick
>
Re: guacd not starting on boot
Posted by Nick Couchman <vn...@apache.org>.
On Sun, Mar 10, 2019 at 11:04 PM Robert Dinse <na...@eskimo.com> wrote:
>
> Ok, rebuilt with the correct --with-systemd-dir=/lib/systemd/system
> and
> now I had more problems. Launched out of init.d it ran as root, launced
> out
> of systemd, the unit file it created has User=daemon so it runs as daemon.
> Problem with that is only root has access to /var/run and to the
> encryption key
> file so I changed it back to root despite that being less secure.
>
Or you could change permissions on the files so that the daemon user has
access to them. For the encryption key, this should be pretty
straight-forward:
chown daemon /path/to/encryption/key
For /var/run, I'm not sure why the daemon user would need access to that
directory? I suppose it could if you're adding "-p /var/run/guacd.pid" to
the command line or specifying a PID file in the guacd configuration, but
by default there are no requirements for this. Furthermore, with systemd
in particular, I'm not sure that's there much value to having it generate a
PID - system runs things in the foreground by default and manages tracking
the PID of the daemon, so there's really not much you'd need the PID file
for.
If you do want that PID file in /var/run, for whatever reason, in most
distributions that run systemd /var/run is managed by tmpfilesd, and can be
configured by adding the appropriate file to /etc/tmpfiles.d with the files
and/or directories and the required ownership and permissions.
>
> Lastly it still failed because it tried to start before /misc was
> mounted
> which is where the key file was so I modified the unit file line:
>
> After=network.target
>
> to:
>
> After=network.target misc.mount
>
> /misc is the file system where I have the encryption certs and keys.
>
> Now it starts properly after a reboot. Downside, as with when it ran
> out of /etc/init.d, it is running as root which from a security perspective
> is undesirable.
>
But, this is your choice, not a requirement - you've changed it from daemon
to root to resolve other issues that should be resolved with either a chown
(or ACLs) and proper configuration.
>
> What guacd should have is an item that goes into guacd.conf for user
> and
> group so it can start as root, write the pid file and read the necessary
> cert and key files, and then switch to said user and group just like Apache
> httpd and tomcat do.
>
httpd does this, Tomcat does not. Tomcat is started by the startup.sh
script, and that script must be run under the account that you want running
Tomcat. Tomcat does not implement user context switching at startup, and
should (IMHO) *never* be started as root.
>
> Then it could be both secure and functional.
>
There may be some value to looking into doing this - having the initial
user be root and then switch to another user - but please understand that
it is not required to make guacd both "secure and functional" as it is
implemented today. There is no reason at all that you cannot set
permissions on all of the required items - GUACAMOLE_HOME (/etc/guacamole),
encryption keys and certificates, and the necessary /var/run entries - to
the user specified in either the init script or the systemd file (+
tmpfiles.d) so that guacd runs under a non-root account. You don't have to
use the daemon user if you don't want to - this was a convenient default
for the systemd unit file when we added it - you can create a separate user
for guacamole (I often use "guac") and change permissions to that user
along with the systemd script, and you will be able to operate in both a
"secure and functional" fashion.
Furthermore, there are other methods you could use to protect guacd and the
required files, like chroot jails or Docker containers. Docker is already
available, and, while chroot jails are not implemented by default, the
requirements for guacd are reasonably simple enough that it should be
doable with minimal effort.
The point here is that, while there may be some value to having guacd start
under root and switch internally, there's no reason you have to do this in
order to make guacd function and function securely.
-Nick
Re: guacd not starting on boot
Posted by Robert Dinse <na...@eskimo.com>.
Ok, rebuilt with the correct --with-systemd-dir=/lib/systemd/system and
now I had more problems. Launched out of init.d it ran as root, launced out
of systemd, the unit file it created has User=daemon so it runs as daemon.
Problem with that is only root has access to /var/run and to the encryption key
file so I changed it back to root despite that being less secure.
Lastly it still failed because it tried to start before /misc was mounted
which is where the key file was so I modified the unit file line:
After=network.target
to:
After=network.target misc.mount
/misc is the file system where I have the encryption certs and keys.
Now it starts properly after a reboot. Downside, as with when it ran
out of /etc/init.d, it is running as root which from a security perspective
is undesirable.
What guacd should have is an item that goes into guacd.conf for user and
group so it can start as root, write the pid file and read the necessary
cert and key files, and then switch to said user and group just like Apache
httpd and tomcat do.
Then it could be both secure and functional.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Sun, 10 Mar 2019, Nick Couchman wrote:
> Date: Sun, 10 Mar 2019 21:09:14 -0400
> From: Nick Couchman <vn...@apache.org>
> Reply-To: user@guacamole.apache.org
> To: user@guacamole.apache.org
> Subject: Re: guacd not starting on boot
>
> On Sun, Mar 10, 2019 at 8:07 PM Robert Dinse <na...@eskimo.com> wrote:
>
>>
>> I have guacd installed, built with the --with-systemd flag and it
>> does
>> not install a systemd file but an initd file which systemd recognizes and
>> says it installs however, while systemctl start guacd works fine and
>> systemctl enable guacd indicates it did the right thing, it does not start
>> upon boot, I have to manually start it. Because some of the things it uses
>> are on NFS partitions, I suspect it's trying to start before NFS is up and
>> failing.
>>
>>
> A couple of notes:
> - The "--with-systemd" flag is not valid. The flag is
> "--with-systemd-dir=<directory>", where directory is the location where
> you'd like the systemd files installed. Can you please verify if that's
> the flag you're using, and if you're specifying a directory, like
> /etc/systemd/system or /usr/lib/systemd/system?
> - Have you tried removing the initd file, reloading systemd (systemctl
> daemon-reload) and seeing if the systemd unit then references the unit file
> (assuming it's actually being installed)?
> - If you have guacd running in a situation where NFS is required for guacd
> to start you're going to have to make some modifications to either the
> initd script or the systemd script. It sounds like, in this case, that the
> issue is not with either the guacd initd or systemd files, but with a
> customized environment you have. That's fine - we certainly don't expect
> every environment to follow the ones we're used to; however, you may have
> to do a little tweaking to the scripts to make them wait for NFS to be up
> before starting guacd, if guacd is on a NFS share. I would suspect even if
> you get the systemd script to install that you'll still have the same
> issue, because the standard systemd unit file we provide does not require
> NFS to be up. Fortunately, those changes should be relatively trivial to
> either the initd script or the systemd unit file.
>
> -Nick
>
Re: guacd not starting on boot
Posted by Nick Couchman <vn...@apache.org>.
On Sun, Mar 10, 2019 at 8:07 PM Robert Dinse <na...@eskimo.com> wrote:
>
> I have guacd installed, built with the --with-systemd flag and it
> does
> not install a systemd file but an initd file which systemd recognizes and
> says it installs however, while systemctl start guacd works fine and
> systemctl enable guacd indicates it did the right thing, it does not start
> upon boot, I have to manually start it. Because some of the things it uses
> are on NFS partitions, I suspect it's trying to start before NFS is up and
> failing.
>
>
A couple of notes:
- The "--with-systemd" flag is not valid. The flag is
"--with-systemd-dir=<directory>", where directory is the location where
you'd like the systemd files installed. Can you please verify if that's
the flag you're using, and if you're specifying a directory, like
/etc/systemd/system or /usr/lib/systemd/system?
- Have you tried removing the initd file, reloading systemd (systemctl
daemon-reload) and seeing if the systemd unit then references the unit file
(assuming it's actually being installed)?
- If you have guacd running in a situation where NFS is required for guacd
to start you're going to have to make some modifications to either the
initd script or the systemd script. It sounds like, in this case, that the
issue is not with either the guacd initd or systemd files, but with a
customized environment you have. That's fine - we certainly don't expect
every environment to follow the ones we're used to; however, you may have
to do a little tweaking to the scripts to make them wait for NFS to be up
before starting guacd, if guacd is on a NFS share. I would suspect even if
you get the systemd script to install that you'll still have the same
issue, because the standard systemd unit file we provide does not require
NFS to be up. Fortunately, those changes should be relatively trivial to
either the initd script or the systemd unit file.
-Nick
Re: guacd not starting on boot
Posted by Mike Jumper <mj...@apache.org>.
You don't need a threaded reader - just choose the most relevant message
and reply to that, as you would with any email conversation.
- Mike
On Sun, Mar 10, 2019, 17:39 Robert Dinse <na...@eskimo.com> wrote:
>
> Sorry I am not precisely good at remembering what I put in the
> starting
> line. You might use a threaded mail reader, not everyone, including
> myself,
> does.
>
>
> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
> Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
> Knowledgeable human assistance, not telephone trees or script readers.
> See our web site: http://www.eskimo.com/ (206) 812-0051 or (800)
> 246-6874.
>
> On Sun, 10 Mar 2019, Mike Jumper wrote:
>
> > Date: Sun, 10 Mar 2019 17:36:34 -0700
> > From: Mike Jumper <mj...@apache.org>
> > Reply-To: user@guacamole.apache.org
> > To: user@guacamole.apache.org
> > Subject: Re: guacd not starting on boot
> >
> > Robert, please stop recreating your threads with new subject lines. It
> > splits the conversation unnecessarily when the topic is not changing.
> >
> > For anyone encountering this thread, please see the original thread
> titled
> > "guacd startup":
> >
> >
> https://lists.apache.org/thread.html/0fec8a9906c86318b4de4356174c67492aa61aad3dc4a743fe87e9ee@%3Cuser.guacamole.apache.org%3E
> >
> > - Mike
> >
> >
> > On Sun, Mar 10, 2019 at 5:07 PM Robert Dinse <na...@eskimo.com> wrote:
> >
> >>
> >> I have guacd installed, built with the --with-systemd flag and it
> >> does
> >> not install a systemd file but an initd file which systemd recognizes
> and
> >> says it installs however, while systemctl start guacd works fine and
> >> systemctl enable guacd indicates it did the right thing, it does not
> start
> >> upon boot, I have to manually start it. Because some of the things it
> uses
> >> are on NFS partitions, I suspect it's trying to start before NFS is up
> and
> >> failing.
> >>
> >>
> >>
> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
> >> Eskimo North Linux Friendly Internet Access, Shell Accounts, and
> Hosting.
> >> Knowledgeable human assistance, not telephone trees or script
> readers.
> >> See our web site: http://www.eskimo.com/ (206) 812-0051 or (800)
> >> 246-6874.
> >>
> >
>
Re: guacd not starting on boot
Posted by Robert Dinse <na...@eskimo.com>.
Sorry I am not precisely good at remembering what I put in the starting
line. You might use a threaded mail reader, not everyone, including myself,
does.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Sun, 10 Mar 2019, Mike Jumper wrote:
> Date: Sun, 10 Mar 2019 17:36:34 -0700
> From: Mike Jumper <mj...@apache.org>
> Reply-To: user@guacamole.apache.org
> To: user@guacamole.apache.org
> Subject: Re: guacd not starting on boot
>
> Robert, please stop recreating your threads with new subject lines. It
> splits the conversation unnecessarily when the topic is not changing.
>
> For anyone encountering this thread, please see the original thread titled
> "guacd startup":
>
> https://lists.apache.org/thread.html/0fec8a9906c86318b4de4356174c67492aa61aad3dc4a743fe87e9ee@%3Cuser.guacamole.apache.org%3E
>
> - Mike
>
>
> On Sun, Mar 10, 2019 at 5:07 PM Robert Dinse <na...@eskimo.com> wrote:
>
>>
>> I have guacd installed, built with the --with-systemd flag and it
>> does
>> not install a systemd file but an initd file which systemd recognizes and
>> says it installs however, while systemctl start guacd works fine and
>> systemctl enable guacd indicates it did the right thing, it does not start
>> upon boot, I have to manually start it. Because some of the things it uses
>> are on NFS partitions, I suspect it's trying to start before NFS is up and
>> failing.
>>
>>
>> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>> Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
>> Knowledgeable human assistance, not telephone trees or script readers.
>> See our web site: http://www.eskimo.com/ (206) 812-0051 or (800)
>> 246-6874.
>>
>
Re: guacd not starting on boot
Posted by Mike Jumper <mj...@apache.org>.
Robert, please stop recreating your threads with new subject lines. It
splits the conversation unnecessarily when the topic is not changing.
For anyone encountering this thread, please see the original thread titled
"guacd startup":
https://lists.apache.org/thread.html/0fec8a9906c86318b4de4356174c67492aa61aad3dc4a743fe87e9ee@%3Cuser.guacamole.apache.org%3E
- Mike
On Sun, Mar 10, 2019 at 5:07 PM Robert Dinse <na...@eskimo.com> wrote:
>
> I have guacd installed, built with the --with-systemd flag and it
> does
> not install a systemd file but an initd file which systemd recognizes and
> says it installs however, while systemctl start guacd works fine and
> systemctl enable guacd indicates it did the right thing, it does not start
> upon boot, I have to manually start it. Because some of the things it uses
> are on NFS partitions, I suspect it's trying to start before NFS is up and
> failing.
>
>
> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
> Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
> Knowledgeable human assistance, not telephone trees or script readers.
> See our web site: http://www.eskimo.com/ (206) 812-0051 or (800)
> 246-6874.
>