Posted in General Discussion / Computer Talk
Author: soleimanian Total-Replies: 8
How to Disable Password Expiration
By default, In Windows XP passwords have an expiration date and Windows XP user Passwords will expire after 42 days, and when you try to log on, Windows XP display below message:
"Your password will expire in 14 days.....".
To disable Password Expiration:
Go to Control Panel > Performance and Maintenance > Administrative Tools > Computer Management or
Click Start > Run > and type control userpasswords2 and click OK to run User Accounts
Click the advanced tab, and then press the advanced button.
Select Users in the Local Users and Groups
In right side, double click on your username, in General tab, check “Password never expires” and finally click ok
Posted in Computers & Tech / Operating Systems / Windows (All Versions)
Author: faulty.lee Total-Replies: 22
QUOTE (FeedBacker)Administrator Account Problem In Microsoft Xp [solved]
Link: view Post: 118790
Why "[solved]" ???
I'm assuming you're logged into a local machine. If you've logged into a domain machine, then you'll need to get the "human" administrator to help you with that.
You need to login as Administrator and configure your right/permission or user type of your account.
DISCLAIMER : This is suppose to help you in case you forgot your password or lock yourself out. It's not meant to be use for unlawful act. Do at your down RISK !!!
Windows XP installation should come with an Administrator account by default, and normally no password is set. A default user is later create to prevent from using the admin account all the time. With the Welcome Screen, you don't get to login as admin. So you need to switch to safe mode. When booting your PC, press F5, until you see a list of file shown on the screen. When you reach the login screen, try login with "Administrator" without any password.
If the above don't help, that means your admin is set with a password. You need to download a tool to do it.
chntpw - http://home.eunet.no/pnordahl/ntpasswd/bootdisk.html
Download the bootable cd image, then burn into a blank cd. Follow the instruction given on the page. Remember, it's recommended to set the password to blank, you can always change it once you can login.
I've used this many time to help myself and to help my client as well.
Posted in Computers & Tech / Operating Systems / Windows (All Versions)
Author: NilsC Total-Replies: 10
You can bypass Windows XP passwords by using a W2k boot disc!
M$ tried to make XP the securest version of Windows OS. This hole in the security are the norm not the exception! Since the flaw was found, why not use it for something.
So if you are the proud owner of a w2k CD or have access to one, just pop it into the CD rom and boot the computer. Now you can go into the W2k recovery console. If you use a W2K CD on a W2K computer you need a password to start the recovery console, no such thing in XP. In recovery console you can now access all files on the computer you can copy and paste them to a disk or or other removeable media - memory stick anyone!
So with unrestricted access to the computer it does not matter if you password protected the forlders any file by any owner can be accessed. This now opens the door for that same person to install programs. They can setup a backdoor program and grant themsef full access or what if a nice keystroke logger was installed. Next time they have access to the computer they can retrieve that data and get passwords you used.
On a XP pro you can at least protect your files with EFS (encrypted file system) if you have installed XPP with NTFS. With XP Home you are out of luck, EFS are not enabled with the home version.
If you are usig a computer in a place like a college campus, at work, for travel or at home with multiple users you can turn on 1 protection. (this works for desktops and laptops alike)
Turn on the BIOS Password with a BIOS password in place the CD can not bypass and boot your computer. So until M$ releases a patch for this flaw, turn on BIOS password and make sure it's not the same as your regular password and store it in a secure place.
Posted in Computers & Tech / Programming / Scripting / PHP
Author: vicky99 Total-Replies: 8
I need a PHP script which can verify users. There should be a system which set access level of users. I mean admin, power user and the regular user. Admin will have all the rights like block user change password etc. and power user can have rights more than regular user. I want to build a Content Management System. For which I need your help. Bye.
Posted in Astahost / Hosted Members Support / cPanel
Author: Rudy Total-Replies: 12
I support what you are saying and think that management should consider making the change to hide the login name.
If I had bad intentions it make it easier by having half my work done for me if I already know the login name. All I would have to tangle with is only the password.
I have question it myself several times.
I went into my profile and removed it and it don't show any more. Also everything seem to be fine, no problems created.
Thu Feb 3, 2005 New Discussion
Posted in General Discussion / Computer Talk
Author: mariamb Total-Replies: 14
I understand about to to set the computer start on automatically.
However, my computer required user ID and password to log on.
(I can't remove the user ID and password).
Is there anyway to start on and log on automatically together?
Posted in Computers & Tech / Networking
Author: yordan Total-Replies: 5
you are the user exactly as if you were on the keyboard.
What I do is the following :
I physically go on the remote machine, and I create a standard user, preferably a "rksh" (restricted shell) user.
I check that this user has permissions enough for doing his job (let's say administrating the webserver files).
I check that this user does not have system permissions (he does not know the root password)
This user starts vncserver.
This user sets the vnc remote access password by means of typing "vncpasswd", you are prompted for the remote access password, keep this password secret. This remote access password should not be the user password, don't make things too simple.
vncserver tells something like "you can connect IP XXX.yyy.zzz:h" (h is the terminal ID, usually 1 for the first user, 2 for the second one, etc...)
At this time your remove the keyboard and mouse and you go to your main compute.
You start vnc, which asks you the remote system idi, you enter XXX.yyy.zzz:h
You also enter the remote access password and you are on the remote system, exactly if you were on your own system. You can even click "full screen" and you even don't know that you are on a remote system. Simply you cannot alt-ctrl-del, you have to click "send ctrl-altdel" !
Posted in Computers & Tech / Programming / Scripting / PHP
Author: yordan Total-Replies: 6
QUOTEWe store the pass word of Mysql in a file right.
No, we don't really store the password in a file. This is the main principle of passwording.
The database administrator assigns a password.
This password is enkrypted somewhere and is never read.
The algorithm is made in such a way, that there is no real "reverse function" allowing to know the real password from the stored value.
And, of course, the password is not a word in a file. It's part of the binary files, the bytes lying along the file from offseen XXXX to offset YYYY. The database manager knows he has to go from offset XXXX to YYYY while reading, but you don't know.
So, the only way of coming in is asking the database manager to connect you.
And the database manager accepts your password, or refuses it.
Generally, if you try three times, it was your last chance, sometimes the IP address is blacklisted, sometimes the user is simply locked until the admin enables it again.
Of course, you can try using a computer to try to guess the password of another computer, but usually this needs time, and the admins are warned that something is occuring.
And have a look here, at astahost, there are peoples from all around the world. You can easily imagine that one admin is not sleeping right now, somewhere in the word.
Posted in Free Web Hosting / Hosting Support & Help
Author: OpaQue Total-Replies: 7
Your domain is working perfectly at my place.. This is what I get
QUOTEWelcome to your Hosting Account!
This site is currently Hosted at astaHost.com
If you are seeing this message then it means that your site is up and your account is functioning properly.
Please see to it that you do the following steps before you continue :-
Login to your cpanel by typing, http://yoursite.com/cpanel.
Enter the userID and Password.
Change the Email address in your Cpanel. (used to recover your password incase you lose it)
Change the Password in your Cpanel.
:: Free Hosting account holders::
In order to keep this service alive and also you hosting, you must be active at the forums.
Please contribute your knowledge at the forums.
If you cannot stay active for any reason, you have to notify the administrators.
You agree that you will follow the Terms of service.
You are NOT supposed to use this account for giving out downloads, sharing of Mp3's, publishing explicit material, Porn, Hatred contents, Illegal downloads, cracks, warez, Copyrighted material, as temporary file storage etc.
Any breach of the agreement shall result in your account termination without notice.
We do not take responsibility of the user data and we recommend every user to back up the data on a regular basis.
Fri Dec 31, 2004 New Discussion
Posted in Astahost / Hosted Members Support / IRC Support
Author: SilverFox Total-Replies: 11
Ok type /msg ChanServ INFO #channel ALL
QUOTE1. Is there a way to see a list of all the options (settings) for my channel? For example, the current modes set (voice, who can set topic, secret channel, etc.). This and others...(channel info, etc.).
QUOTE2. How do I use the word filter? Any way to add them in groups instead of one by one?
I don't know.
Register it so you can leave it. /cs REGISTER #channel PASSWORD DESCRIPTION
QUOTE3. For the mlock feature, is there any way we "append" to the permissions? Because it looks like if I forget to put all the mode settings, it will automatically reset to +r instead (and I don't want to configure everything only to make a mistake like that and have it reset everything). Also, do I have to use mlock in order to keep the mode settings? I tried using /mode but if I logout and come back to my channel all mode settings are reset to default again.
QUOTE4. How do I add a description to the server for everyone to see (when they use /list)? Tried the desc already and seems to set only channel one (not in server list description).
It uses the TOPIC set.
I don't know. It might be that SErvices setting.
QUOTE5. Also, why can't I do some of the things (like /mode #my_channel) if I didn't join my channel yet? I registered it already though...
Type /os mode #channel MODE
That's if you are super admin.
QUOTE6. How do I add a rule/policy for my chatroom like I see when I first join a server?
You cannot set that for your local channel unless you make a bot that does it when someone notices it with a certain word.
QUOTE7. Is there a way to hide the permission settings from regular members (like so and and so set +r for...)?
Probably but itd be using services.
I hope that helps. I help run a server FYI. I don't recommend auto-opping people who join. Just Half OP (%/Access Level 4) or have a special servant who is protected op (&/Access level 10)
What I said is for unrealIRCD 3.12, non-ssl installation.
Posted in Computers & Tech / Operating Systems / Windows (All Versions)
Author: miCRoSCoPiC^eaRthLinG Total-Replies: 5
Generic Host Service is directly related to a file named svchost.exe found both on Win2K and WinXP - this file itself isn't a service, but it helps running several different windows services dynamically as demanded by the OS. Normally you'd see around 3-4 copies of this service running if you open your Task Manager and see the process list. If you have more than 4 - it's trouble brewing (or already hard brewed) for you. Since this file handles lots of important but regular tasks of the OS, this is the most likely target for virii and worms. Most such virii attach themselves to this file causing it to malfunction and print out such error messages quite often.
First thing you should do is do a thorough virus check of your system again - also check for Worms like Blaster which are known to make this file a prime target. If all else fails, check the file size on your system and compare it with a clean system. See if there's any difference. Sometimes even bad RAM can fire off such errors.
If you want to read more about these services, check out this article:
The last area of reliability improvements is in the area of the services infrastructure. Prior to Windows 2000, some services shared a process with other services and some ran in their own process. Windows 2000 introduced the generic service host process, Svchost.exe. The goal was to reduce system resources by consolidating the various processes hosting built-in operating system services into a single process. Or, it could permit the system administrator to configure the system to run certain services in their own processes, which would prevent one service from corrupting the private memory of other unrelated services (this capability is not documented or supported yet).
If you look at the Windows XP process list in Task Manager , you will notice at least four Svchost.exe processes: two running under the SYSTEM account (sometimes referred to as LocalSystem) and two running under two new service accounts: NETWORK SERVICE and LOCAL SERVICE.
One of the two Svchost processes running under SYSTEM hosts the bulk of the services, 29 of them in total. The second one hosts a single service, Remote Procedure Call (RPCSS). The reason this service needs to be in a separate process is that user-written DLLs are loaded into this process. By having RPC running in its own process, these DLLs cannot adversely affect the operation of the other built-in operating system services. The Svchost process running under NETWORK SERVICE hosts a single service, the DNS Client. The Svchost process running LOCAL SERVICE hosts the TCP/IP NetBIOS Helper, Remote Registry, Simple Service Discovery Protocol, and Web Client services.
The reason for the two new service accounts is to improve system security by reducing the privileges that services run with. LOCAL SERVICE is a built in account that doesn't need a password to log on. The account has only a few privileges, and is not a member of the local administrators group. So, if a service that is running under this account is compromised, it cannot take down the whole machine. LOCAL SERVICE also has no network credentials, so attempts to access a machine on the network will connect with the null session. The NETWORK SERVICE account has the same set of privileges as LOCAL SERVICE, but has access to the machine's credentials for outbound connections, similar to the SYSTEM account.
Some more articles with similar problems as yours:
Posted in Computers & Tech / Operating Systems / GNU/Linux
Author: dserban Total-Replies: 2
SSH is an important tool in Linux / UNIX and an amazing piece of software. It's one of the top 2 or 3 things that an experienced Linux / UNIX system administrator uses every single day.
People use SSH to connect to their home machines from work and to their servers from both work and home.
People use SSH in backup scripts.
People use SSH for lots of other things.
There is some interesting history about SSH - it was originally developed by some company and the original versions were actually open-sourced, and then they closed it up at some point but then some other developers took the last open source version and created a new open source release which was then later picked up by all the OpenBSD guys and turned into OpenSSH, which is the actual piece of software that we all use (ssh being one of the tools that comes with OpenSSH).
Basically, SSH is a secure replacement for telnet. It lets you network in remotely to machines from other machines (either across a local network or through the Internet), so you can access a server that is sitting across the room as easily as you can access a server that is on the other side of the world, or you can access your workstation that is sitting in the basement of your house from your laptop while you're sitting upstairs.
It's very secure both in the connection as well as of course in the transmission of the data back and forth. I'm hesitant to say it's totally secure, knowing what I know about another technology called IPSec. SSH encrypts the data at the TCP level. IPSec, as the name implies, encrypts the data at one level below in the OSI model, the IP level, which makes it more secure than SSH.
SSH is so essential that every distribution comes with it. I would be really surprised if there was any distribution that didn't.
So you can open up a terminal and type:
and find some information about SSH.
The SSH configuration files are in /etc/ssh typically. There are two files in there:
ssh_config (the configuration file for the SSH client)
sshd_config (the configuration file for the SSH daemon / server)
How you start, stop or restart SSH usually depends on the distribution, but in most of them you would type at the command prompt as root - or by prepending sudo:
CODEsudo /etc/init.d/sshd (start|stop|restart|status)
So how do you use it?
Let's come up with a hypothetical scenario.
Let's say you have a Linux server in the basement, and let's say the machine is called "server" and then let's say you have a laptop, and you want to be able to connect to your server from your laptop, and let's say your server has two users defined on it: root (obviously) and a regular user called joe.
Let's say the laptop runs Linux and also has users root and joe.
So you have the same users on both machines.
You need to start the SSH daemon on the server machine, then, from the laptop, open up a terminal and simply type:
That's all you have to do to start with.
Now a couple of things are going on here.
First of all, by not using a user name in the command, SSH assumes that you are going to try to ssh in as the same user that you are logged in as on the laptop.
So if you are logged in to the laptop as joe, you will be ssh'ing into the server as joe. You don't need to include that because it's the same user.
If you want to log into the server machine as a user other than the one you are logged in as on the client side (root, for example), you would simply type:
And then the other thing that's going on here is using the word "server". That's the machine name of the computer you want to connect to, and that's assuming that on your network you can find that name. You can always edit your /etc/hosts file and put the IP address of the machine in there and associate it with the string of characters "server", as another way to connect the IP with the name.
You can also use an IP address in the ssh command, so you could also do:
if that is your server's internal IP address.
When you first try to ssh into the server from the laptop, you will see on the laptop screen, in your terminal, some text that prompts you to accept the fingerprint of the machine you are trying to connect to.
Basically, the laptop is going to "save the fingerprint" of the server that you are connecting to. That way in the future it can recognize that it's the same machine, the idea being that this way if some other machine is pretending to act as your server and doesn't have the same fingerprint, the ssh client will immediately warn you that the fingerprints don't match.
That fingerprint gets added to a file called known_hosts on the laptop, in a hidden directory called .ssh in your home directory. That hidden .ssh directory is where all of your ssh-related user files are kept.
At this point ssh will ask you for the password of the user joe on the server machine, you type it in and you're in.
That's it - very easy, very secure (the whole thing is encrypted from the beginning to the end, the connection itself where you type the password is encrypted all the way along the way).
Something else that you can do with SSH is you can use a facility / command called "secure copy" or scp. It acts just like the cp command (the Linux copy command), except the copying process is taking place in a secure manner.
To give an example, let's say you have a file called file1.txt on your laptop, and you want to copy it over to joe's home directory on the server. On the laptop you would open up a terminal and type:
CODEscp file1.txt server:file1.txt
Basically, it's the same convention as with cp - you enter the command name, and then the first argument is the name of the file you're copying, and the second argument is the destination. Technically, the destination is the fully qualified file name (with the full path prepended to it), so you would really type server:/home/joe/file1.txt (and of course you can use the ~ character instead of /home/joe).
That will copy file1.txt from the laptop over to the server, using scp, which is basically secure copy over SSH.
That's fairly easy and straightforward, but what I would encourage you to check into and adopt is the concept of public and private keys with SSH. There is a lot of information out there about the whole idea of cryptography using public and private keys, so I won't get into it in very much detail. Basically, you create a private key and a public key that kind of fit together and work together to "unlock the secret" (unlock the e-mail in the case of GPG or unlock the connection in the case of SSH). It's a way to make a connection without using passwords and it will only work if you have both the private and the public key together - they have to fit together and you can't figure out the private key from having the public key. The public key is supposed to be out there, given away, put on other machines, given to other users (in the case of GPG) etc... and you keep the private key to yourself.
The idea of using public and private keys is really great because it does 2 things.
One is that it's more secure than using a password, simply because passwords can be compromised more easily than you can imagine, unless you are really good at remembering a really long random alphanumeric password. Public and private keys really can't be compromised. I'm sure theoretically of course anything is crackable, but in practice, these types of public and private keys have not yet been cracked, so it's very, very secure, much more secure than using passwords.
The other benefit of using public and private keys is that it makes the SSH connection completely seamless. In our previous example, we had to enter joe's password on the server machine, but with keys you don't need to enter passwords. To accomplish that, and supposing we are logging in as another user (different from the one we are logged in as on the client side), we are going to create a key pair on the client machine. In the terminal, we would type:
CODEssh-keygen -t rsa
This will create 2 files in the .ssh directory: id_rsa and id_rsa.pub, with id_rsa.pub obviously being the public key.
So now that we have both the private and the public key on the laptop, the idea is that we need to get that public key over onto the server somehow, because when we connect to the server, we will have the private key on the laptop and the public key on the server, the two will match together, and our session will be authenticated, and we can come right in without any password.
It is very easy to copy a key over: you go into the .ssh directory on the laptop, and you type:
CODEscp id_rsa.pub server:/home/joe/.ssh/.
and that would just copy the file over to the server.
And there is still another step.
You now need to ssh into the server and cd to the .ssh directory:
... and so joe is in the hidden .ssh directory, where that id_rsa.pub file now resides. Look for a file called authorized_keys, and if it's not there, type the following:
That authorized_keys file is going to contain all the public keys of the users who are connecting to the server, but now there is nothing in it yet, so type the following:
CODEcat id_rsa.pub >> authorized_keys
and what this command is doing is it's taking the contents of the id_rsa.pub file and appending it to the bottom of the authorized_keys file.
Make absolutely sure that you use two "greater-than" signs - you don't want to overwrite the contents of the authorized_keys file, should any keys have previously been stored in it.
At this point, joe should be able to open up a new terminal and type:
and he should be logged in right away without having to enter any password.
Because it doesn't ask for any passwords, this is actually very handy because it opens up a whole new world of possibilities for securely automating administrative stuff. You can kind of see now some of the things you can do with it: scripts that do automated backups over SSH, business application interface file transfers ... there are all different kinds of things that can be done when you have these public and private keys.
But obviously the important thing is that you don't want to lose your private key that is stored on the laptop - that is the real bottom line security issue.
That, in a nutshell, is basically the way to use ssh with public and private keys. I will describe the configuration and security stuff further down below, but there is one little neat trick with ssh - one of the other switches for the ssh command is "-D", and that stands for "dynamic". What that does is that, if you put a port number after it, it will let you sort of tunnel an SSH connection to a local port. It specifies a local "dynamic" application-level port forwarding. You can use it as a web proxy. An example of this is the following:
CODEssh joe@server -D 8080
from a terminal on the laptop, and you're connected. Now, what you can do with a browser like FireFox or Konqueror is you can go into the advanced preferences in the section where you have the option to manually set the proxy server, go down to the SOCKS proxy configuration line, and in the first box enter localhost, and then in the port box enter 8080, and then confirm / save it.
The next time FireFox is going out to browse a web page, it is going to be tunneling its web browsing through SSH. You can actually verify this with one of those sites that shows you your IP address, like http://www.ipchicken.com/ ... what I've done is I've opened up FireFox, gone to ipchicken, looked at my IP address, then I've done this ssh thing with the "-D 8080" option, changed the proxy settings in the browser, refreshed the ipchicken page and my IP address had changed, because I'm now browsing through the server, through the remote machine. It's very handy if you're in places like hotspots, where you may be concerned about people sniffing or whatever is being tracked through your web browsing - you can just connect to another machine over SSH and pull down this dynamic port to your local machine on 8080, change your browser's proxy settings, after which your browsing will go through your encrypted SSH session - very slick. There is a FireFox extension called SwitchProxy ( https://addons.mozilla.org/en-US/firefox/addon/125 ) which lets you create "proxy profiles" so you can have one without this SOCKS setting, for just normal browsing when you're at home and you're not worried about invasion of privacy, and then one with the 8080 proxy SOCKS setting for when you're wanting to do this SSH tunneling thing.
Some basic security things with SSH that I would recommend:
One thing I would do is go into the /etc/ssh directory and then open up for editing the sshd_config file (again, this is the configuration file for the SSH daemon), so this would be on the server machine, not the laptop, because you want to make the security changes on the machine that is going to be offering up SSH. The first thing you want to do is change the default port from its default of 22 - that's very simple to do.
It's amazing - someone I know had a web server and they had the SSH listening port set to 22 for one single day before he got around to changing the default port (he had everything set up with passwords so he wasn't worried about anyone actually getting in) but at the end of that day he was checking the logs with LogWatch, which is a great little utility that parses through your system logs and you can set it up to e-mail you a daily log of everything that had been going on with the server, and it listed all the SSH attempts, and he said it must have been like a thousand in that one single day, and it was all of course script kiddie scripts and bots, but it was amazing because it was showing you the attempted user names, and it just went through the alphabet, but it's pretty frightening actually that they would try all these different random names that were in this script and see what works and I guess that if they find one that connects, then they'll just start doing a dictionary attack on the passwords.
So, anyway, what I would do is definitely change the default port from 22 to just some random port number - pick a high number (you know, 11500 or something), and of course, whatever port you end up using, if you are going to connect from the outside world to your machine, don't forget about your firewall and your NAT router. You will need to set up a port forwarding rule to forward whatever port it is to the machine that's going to be serving up the SSH server (just like with any service that you've got running behind your firewall, if you want to get to it from the outside, you have to forward that port to that machine).
A couple of other tweaks to the sshd_config file:
I would change the protocol from 2,1 to just 2 - that's because SSH protocol 1 is slightly less secure. Most things that I've come across suggest changing that to 2 only.
I would also disable root logins (you will see a line in there somewhere that needs to be set to
it's usually either set to yes or the line is commented out, which also gives it a default meaning of yes). And if it's yes, it means the root account on the server could ssh in - you don't want to do that, just from a security standpoint. You want to limit it to just regular users, and then, once you've connected in through ssh, if you need to do something that requires root privileges, just su to root or do the sudo thing - that way someone would have to get through two levels to get to a root level of authorization, they would have to go through SSH with a regular user, and they would also have to know your root password. So disabling root logins is a good idea.
The last thing I want to mention is somewhat dangerous. Once you get your public and private keys set up, if you want, look through this sshd_config file and you will see a couple of lines in there about disabling passwords entirely - meaning it will only look for keys. SSH by default will first look for public-private key combinations, and then it will ask you for passwords, if it doesn't find the keys. So you can set it up to just take keys only, and that's pretty secure because using a public-private key combination is better than using a password, but that also means that if you lose your private key you can't get in (at least remotely) - you would have to go sit in front of the server and log on from the physical console and change it back to allow passwords to be able to ssh in. But that's an option to keep in mind.
That, in a nutshell, is SSH. There is a lot more you can do with it. You can for example forward X sessions, meaning you can run graphical applications over SSH.
If you're using Windows and need to SSH into a Linux / UNIX box, your first option is to use the command line tool ssh.exe that comes with cygwin, as a second option look for an open source program called PuTTY, which is a full-blown SSH client with the ability to create key pairs, and it can also deal with pre-existing pairs.
Posted in Computers & Tech / Networking
Author: Soleq Total-Replies: 14
Of course it's possible, and it's a great thing to have.
Because XP directions were already given, I'll post the OS X way.
First, you need to have File Sharing turned on, which is in the Sharing pane of the System Preferences. Turn on Fire Sharing, and voila, you can set options concerning how people can access your computer. To actually connect to a computer on the network though, you need to (on the client computer) go to "Go" in the menu bar, and then Connect to Server. Enter the server address, or you can browse, but then connect and you'll be prompted for your username/password. This should be your regular login name and password, though you can create a separate account just for file sharing. That's pretty much it, but remember to turn on File Sharing for each computer you want to access.
Now, a greater concern is wireless security. Now that you have file sharing turned on, people can access your data. If you use a modern router, turn on WPA, or if it's a tad older, turn on WEP. WEP is still pretty easy to crack, but hey, it's something.
Posted in Astahost / Your Voice! Your Review..
Author: Cube Domain Total-Replies: 8
For Those Who Want A Message Board
Reviews and experiences on forum hosts.
By: Andy Lee
Created: September 23, 2005
So you want to jump on the bandwagon and create a message board, eh? This is an article that details my hilarious adventures on forum hosts. Hopefully, this forum hosting guide will help you in your endeavors of running your very own forum-life of solitude.
Disclaimer: Astahost is not responsible for your choices brought as a result of this guidance.
Ezboard - Ezboard is a global online community host. Basically, you choose your own username and can use that username throughout the network. Ezboard is like a prostitute. A prostitute that leeches money off of you but never gives you what you paid for. The ezboard Staff doesn't care about you, the little people. You'd be best off avoiding it.
InvisionBoard - InvisionBoard is great. InvisionBoard is reliable, fast, easy, you get your own server. Basically, nothing can go wrong with this host. Except for one thing. InvisionBoard demands many stacks of cash per month. If you're planning to keep your community intact on it long term, you have to be some rich, bourgeois guy that uses one dollar bills to wipe up with. On the bright side, there are some imitation InvisionBoard service you can go with. Have at that. I recommend InvisionFree.
IkonBoard - Like many things, IkonBoard is generic. It's basically a regular paid message board host, just average I guess. One glamorous thing about it is your community gets a domain name. Watch out though, the Administrators can see your password, which makes it quite a fradulent thing, I guess. If you don't really want a community but rather a place to drill personal information at, sign up for IkonBoard.
PhpBB - Probably the best thing to go, long term. The price is affordable, you are guaranteed reliablility and stability. In fact, the largest message board in the world, GAIA Online [dot] com, uses this. You won't regret using this host.
With these experiences in mind, go out there and achieve your forum-life of solitude. You'll have something to look back at in your retirement home.