Here are some of the trials that I ended up going through..

The next step was to start the installer. I decided to see how the GTK installer had changed from the previous one. Everything was going smoothly until I reached the part to select where to pull my stage file from. I intended to pull it off the Internet, but realized I had not yet setup any IP information on my NIC to be able to connect to anything. On a hunch, CTRL-ALT-F1 did indeed drop me back to a root prompt where I was able to run: net-setup. This quick little network config script just walks you through the basic network configuration. However, it's pretty dumb, and you have to make sure you know all of your settings because it won't calculate or guess anything for you. Most network setup scripts can tell you the broadcast address if you provide an IP and a subnet mask. This one tries to, but after providing a subnet mask of 255.255.240.0, it provided me back a broadcast address that was way off-the-mark. Once I had my network information set, a CTRL-ALT-F7 brought me back in to select and pull the stage file without issue.

Next I went through and selected everything I wanted to install, and after all of that, it began installing. It then errored out and said "Installation Failed" please see the /tmp/install-error-log and report back any bugs. Well there is no /tmp/install-error-log, but there was a /tmp/compile-install-error-log, which told me that you can not install "sendmail" because it conflicts with something else. So I went back through the installation process, and avoided checking sendmail, and the install completed successfully. After a few emerges everything was working quite smoothly.

Granted I could have likely saved myself quite a few headaches by just going through the minimal install CD, and running everything by hand, but I didn't feel like printing off pages of instructions for each step along the way. I've not yet memorized each and every command and step used in the install process, so looking back and forth from my notes to make sure I'm typing every command correctly didn't sound too appealing.

I'm sure many of you that have decided to take Gentoo installations on have likely run into the same, or similar issues that I have. Hopefully my notes above may help someone else complete their installs successfully as well.

Standard Signup Page

Select Your State / Area

Select Your Number

Requested Information

Confirmation / Acivation

Doing a little bit of digging, it looks like all of the local access numbers are being provided by Level3, which has numbers available just about everywhere.

Once you've got your number selected, the activation step is actually done via telephone. You specify which of the numbers you want to be contacted at, and they call you and ask you to enter your confirmation code which they provide to you on the screen. You also get a chance to set your "Spoken Name" and "Personal Greeting" after confirming your account. These are used while handling inbound calls in the future.

At this point the account activation process has been completed, and you're dropped into your main inbox. This is where you can see any messages, or recorded calls that you've got on your account:

I decided to try it out without reading much more, so I picked up my cell phone, and called the number that I had picked. To my surprise, it recognized my number as a number I had bound to my account on setup, and told me I could go ahead and setup my personal account information or listen to my messages. Immediately I recognized a problem: There was no user authorization required to access account details! It is not terribly difficult to spoof the originating number of your call, and quickly access the messages and settings of someone else's account. There may be options to turn on a security feature somewhere in the settings, but by default it seemed to be off.

I then picked up my VoIP phone which I had not bound to my account in any way, and called the Google-provided number. I was prompted to give my name, and was then informed that Grand Central would attempt to find the party that I was calling. My cell phone, and home phone (which I had bound to my account) rang simultaneously. I answered the cell phone, and was greeted with a message telling me that there was an inbound call from "spoken name" and that I had the following options:

1.) Accept the call
2.) Send caller to voicemail
3.) Send caller to voicemail, and listen in
4.) Accept and record the call

When I selected "Accept and record the call" both parties hear "Voice Recording Enabled" and are dropped into the call. So don't figure on using this feature without the other party knowing. The only other nice feature that I like is the ability to send a caller to voicemail while listening in. If you hear something interesting while they're leaving the message, you can break into the call!

After leaving a message, or recording the call the message shows up on your main inbox:

The interface is nice and easy to navigate. You can quickly add the contact information for unknown callers, add pictures, add them to contact groups, etc. The interface provides you with quick access to forward the voicemail/recorded message to others via email, and even quickly post the content to a website via a nice little flash player object. You can even download and save the message as an MP3 for playback and local archiving purposes.

Needless to say, I was quite impressed so far. Then I began to take a closer look at some of the features. There are far too many to cover here in detail, but here are a few that I found quite impressive:

Block Numbers
With the click of a checkbox, you can send any number to the "SPAM" voicemail box, where they will hear the "number not in service" message. There is also a community-based spam filter which allows users to identify abusive telemarketers for example so that everyone can benefit from the community filters.

Notifications
Receive email, and SMS messages when a voicemail is left for you.

Ring Different Phones / Greetings
Set and configure groups to ring different phones based off of time of day, who is calling, etc. You can even specify you own personalized greetings for each one of your groups that you specify. You can specify ring hold music so the caller can hear music while you're being contacted. There are plenty of ways you can have fun with this..

WebCall Button
The concept is simple - Add a WebCall button to your website or blog for people to call you. Your number stays private and you can use all the normal GrandCentral screening, blocking, forwarding, and other features that put you in control. The WebCall button takes care of connecting the call to you after getting the caller's number.

CallSwitch
Change phones in the middle of a call. To switch from one phone to another without hanging up, just press the (*) button while you're talking. Your other phones will ring and you can pick up the one you want and hang up the other. The caller won't even hear the switch.

Click2Call
Easily click on any of the Address book entries, or a missed call number, and they will setup both legs of the call for you - ringing your phone 1st, and then the other party once you pick up. You can specify what number this call will originate from, and they will forge that number during call setup so that it actually looks like the call originated from that number, even though that leg of the call was established by them. I did find one issue here: they won't be providing this feature free forever:

With Click2Call, your GrandCentral number will show as the Caller ID. During our Beta period these outbound calls are free, but will have a small per minute charge in the future.

Mobile Interface
They provide a slimmed down mobile interface where you can access your voicemail, contact lists, and even initiate the calls with just a click. I tried all of the features out from my Treo (700wx), and everything worked flawlessly!

The list of features continues far beyond what I had expected. You can import your Outlook, Gmail, Yahoo, CSV contacts quickly and easily. Ask to re-record greetings through the website where you can specify where you should be contacted via phone for the recording to take place. Many pre-built code snippets for integrating features with your website. With Google now running the show, I expect even better things in the future.

What is really amazing to me is that they are able to offer all of these services including a local number *free of charge*! This is going to be terrible for the traditional telcos that charge premiums for these exact same services (often not implemented nearly as well). Of course I can see Google taking advantage of targeted localized advertising, and integrating one more piece of Google into users everyday Internet use. Overall I'm quite impressed, and this will likely be one of Google's services that I will continue to use.

http://seattlepi.nwsource.com/business/289490_firefox21.html

This is following closely on the heels of Microsoft releasing Internet Explorer 7 last week:

http://news.digitaltrends.com/article11561.html

I've loaded RC3 of Firefox, and I've got IE7 installed on a few systems. Here are some of my reactions to what I've seen so far.

Microsoft has pulled in functionality that has been available in Firefox for years, and has actually improved upon it in my opinion. There is a tab preview screen that shows miniature screenshots of all open tabs. You can click on the screen you want to bring it forward.

Microsoft also turns Cleartype on by default which may improve the way text is rendered on websites. I will be interested to see how this alters web design considerations in the future.

Microsoft has also added some new features such as a quick "zoom" feature located in the bottom right of the status bar. Increasing the number zooms in on the entire site proportionally, even the graphics. This will be a handy feature when showing off a site. There is also a new "Phishing Filter" which I'm guessing is supposed to protect against phishing scams, but since I don't tend to have an issue with that, I'm not sure how much of an improvement this feature is.

There is now a shortcut to delete your browsing history in Internet Explorer (Tools -> Delete Browsing History). I'm not sure this is much of an improvement, but I'm sure some people browsing things they shouldn't be will find it handy.

There is one feature that I really like that has been added in IE7, the ability to quickly and easily manage Add-ons. It was far too easy for an application to hijack your system by attaching itself to Internet Explorer before. Now you can quickly (Tools -> Manage Add-ons) remove a troublesome application that might cause browser instability.

The new default locations for the toolbars in IE7 don't make a whole lot of sense to me. They left the favorites, back, and forward buttons off to the left, and moved everything else off to the far right-side of the browser. So far with the little toying I've done, it doesn't look like you can move them from these locations.

Now for Firefox, there aren't nearly as many readily apparent changes to the browser. There are some slight changes to the way tabbed browsing is handled in v2.0. There is also a new anti-phishing technology to prevent the deceptive disclosure of personal information. It restores windows, tabs, in-progress downloads and text typed into online forms if any of those are interrupted by a system crash. And it corrects the spelling of words entered on Web pages.
Quite handy for things such as blog postings. The look and feel of Firefox has also been much improved in my opinion.

The next few weeks will bring quite a few changes to the browser wars. I've begun using both of them in usability testing for new web development to make sure everything continues to work as it should. Hopefully these new updates will bring some of the guesswork out of CSS functionality and other differences between browsers. What do you think?

http://www.oreillynet.com/pub/a/etel/2006/10/18/solving-the-caller-id-problem.html

There is growing concern over the interaction of VoIP systems with the legacy PSTN, and the transmission of caller identity data--most notably, Caller ID on the PSTN. It is not always possible, or obvious how, to handle Caller ID data when moving to or from VoIP and the PSTN networks. There are even business models predicated on the ability of Caller ID to be transmitted to the PSTN with a value that is not "expected"; call centers are an obvious example, where customer-support staff make outbound calls with a Caller ID that may be from one of many possible clients. More troubling is the possibility that Caller ID may be used to trick unsuspecting call recipients into certain actions or beliefs, and it is this concern that's currently creating a legislative threat I believe must be averted.

I have a proposal at the end of this article that attempts to address these issues, but first some background.

In my opinion, the real threat is not the pending legislation, but other legislation that may likely be appended to it in a year or two's time. That legislation will more clearly identify an impossible or prohibitively expensive technical solution to combat fraudulent Caller ID data from being passed over the network. This would be detrimental to the overwhelming majority of legitimate Caller ID rewrite methods upon which many companies base their business plans, and which many customers have come to expect as basic parts of their service.

At the root of the problem is the desire for law enforcement agencies to have quick and accurate data when trying to uncover who made a call to a certain number. I believe this should be possible, or at least it should be possible when the endpoints are on the PSTN, which is a (more) clearly regulated environment. The problem is that the trust that once existed (possibly falsely) in the PSTN to deliver an accurate Caller ID is eroding due to the flood of interconnecting services that deliver voice but don't have typical E.164 numbering endpoint data associated with them, or that treat E.164 data as a customizable field that may be asserted by the customer. This moves the trust level out another step, which breaks the current model of "phone companies are probably not lying to each other."

For several firms that I have worked in, including my current employer, the Caller ID issue has been a central concern, and the fear of inappropriate legislation puts at risk some of the products and features customers have come to expect. Users without E.164 numbers, users with several E.164 numbers, users wanting to move E.164 numbers to their calling device and network of choice--these users are all affected by the issues that arise with the development of mobile and VoIP infrastructures that decouple devices with E.164 addresses. Advanced combinations of transmitting Caller ID are part of the natural progression of next-generation services, and customers are demanding a better set of methods to control the way their company and personal calls are identified. It's going to get much more complex and customized from the customer and service provider's perspective, and it's up to us as an industry to figure out how to provide accountability for our customers and ourselves to law enforcement agencies.

Assertions

1. Caller ID (and ANI) is insufficient for authentication purposes other than as a "hint." It is wildly irresponsible to assume that the person attached to a device is "authenticated" merely by using that device, when control of those devices has no additional universal, or even commonplace, security policy.
2. Identity presentation should be separate from the network provider. As users become more and more distinct from telephony devices, this will only become more pronounced. This applies to E.164 numbering as well as other identity methods.
3. I do not believe that there is a technical solution to this problem that works on the front-end. SIMs, biometric authentication, or other methods are too complex, or at the least, are going to be selected independently by each vendor. (But I do think there is a solution on the back-end--keep reading.)
4. Law enforcement does need a way to determine who made a call, or at least to what company a warrant should be presented for further data. Currently that does not seem to be the case.
5. I think that the "Truth in Caller ID Act" is probably more political grandstanding than actual effective legislation, since wire fraud statutes already exist that make false impersonation a crime, and I seem to recall already prosecuted cases on the topic of Caller ID. This pre-existing law will not prevent assertion #6...
6. Law enforcement in the United States currently can ask for and receive almost anything it wants as far as legislation. As soon as an investigation reveals that Caller ID rewriting was integral to some type of "terrorism," the industry will find itself at the wrong end of an even more poorly written legislative cannon that will crush companies and investments. Other nations are already in situations where certain products are illegal or relegated to a grey market due to bad legislation, and some will follow the lead of the U.S. I believe that being prepared for this with a prebuilt solution is the only way to avert such a crisis.

Problems to Overcome with Any Solution

1. Many "next-generation" telephony/mobile application firms that are receiving funding right now use Caller ID as a key to their services. I don't think their investors have been shown the potential for fraud yet or understand the threat of legislative hysteria. Hasn't everyone learned from the calling-card business yet?
2. The PSTN cannot turn on a dime and restrict ANI/CLID from many clients using "whitelist" filters. Caller ID manipulation is used too widely for completely legitimate purposes, and any firm providing interconnection will almost always ask for a removal of the ingress filter when sending calls to another carrier. I believe that a "check-ahead database" that is consulted before call completion at any/every border is unworkable as a matter of cost and willpower.
3. Most firms are unwilling to participate in a system where their user data or CDRs with user relationships are centrally managed, as they have serious legal and commercial privacy concerns about the control of that data.

So clearly we have a looming problem. There does not seem to be a feasible solution that works on the front-end (authentication before completion.) And there is a legitimate fear of centralized databases, since many of the service providers don't want to expose their customers to an unknown trust element in the center of the network ("Wait!" you say. "You mean we can't trust AT&T not to give our records to the NSA?"). Legislation will happen if nothing else is inserted into the vacuum, and it will be far more unpleasant than that which is currently proposed. So, what to do?

A Possible Solution

I would suggest an industry-neutral, nonprofit entity that provides:

* A set of agreed-upon rules for member participants regarding:
1. Methods of user and E.164 authentication
2. Acceptable caller ID/ANI rewrite circumstances
3. Acceptable CDR formats, user data, and archive guidelines for internal use
4. Common interface specifications for CDR transmission and LEA access
5. LEA interaction guidelines
* A set of penalties for rules transgressions (removal from membership?)
* A central database that members update with call events
1. An archive of that database
2. A security model surrounding the storage of data to prevent leakage of the minimal (and non-customer identifying) data in it
3. A network-based method to allow members to update their entries
* A method to authenticate law-enforcement request entities
* A method to deliver data to law enforcement upon valid warrant presentation
* A central focus for technical legislative advisory functions ("lobbying")
* A central focus for development and implementation funding that is tax-sheltered

This membership-based organization would serve as a trust broker, both from the perspective of providing "legitimate" firms a safe haven from further regulatory heavy-handedness, as well as providing Law Enforcement Agencies (LEA) with an effective method of pursuing warrants for criminal investigations. The members would be able to safely transmit call data for LEA use without revealing their customer's identities, and the LEA would have a single first point of contact if there were calls about which they want to gather more data.

Members would be any firm that rewrites Caller ID and inserts that into a PSTN or even a VoIP-only network. This can range from VoIP providers who create "on-the-fly" Caller ID on PSTN calls for users with no E.164 address (Skype, Jingle users, SIP users, etc.) to firms that allow users to specify their Caller ID on outbound VoIP calls.

What is in the Database?

You're probably wondering what is in the database. It would contain only a minimal amount of data--whatever is necessary to determine the member from which a particular call originated, but NOT the identity of the end call originator. The most important fields would be originating_member, destination_number, originating_clid, originating_ani, call_start_time, and call_end_time. Data would be inserted into the database after call completion, so this is a "back-end" tracking system and not an authentication system of any kind. The data associating a call event with an end user would be kept by the member organization that created or proxied the call, and would be uncovered by the LEA contacting that member directly. However, the central database would allow LEA to determine what organization was the correct recipient of the next warrant, which I believe is a significant portion of the burden during investigation.

The LEA could come to the clearinghouse and ask, "Were there any calls to 1-XXX-XXX-XXXX starting at approximately 2006-10-06 22:02 from CLID 1-YYY-YYY-YYYY?" The trust broker would then look through the database and respond with something like: "Yes, there was a call matching your request. For further information, you should talk to FooTelecom, Inc. since we know is that such a call took place from FooTelecom, but have no data on the end user who made the call. Here is the data to contact FooTelecom, Inc." An important thing to note here is that this is no more data than is currently exposed in the PSTN, but it allows accountability to the company that made the call. It would seem odd for a firm to object to the data requirements unless they were providing illegitimate use cases to their customers, but that might become more self-evident as time goes on and membership grows.

To speak for my own company: we are happy to comply with any warrant or subpoena presented to us, but at the moment there is no clear way for a LEA to know that they should give the warrant to us as opposed to any other telephony firm interconnected to the PSTN. That scares me for two reasons: first, that there can be calls made on the PSTN that are, for all intents, untraceable after the call event; and secondly, that my first fear is also being felt by LEA, which will ask for the biggest legislative hammer they can wield against companies like my own. For every company in our position, it would be inefficient to set up an independent LEA system since the LEA would then have to ask every company the same question, and the rules and expectations would almost certainly be different for each relationship. That clearly would not scale, so the concept of a central registry for call events sounds more reasonable. No company would be revealing more data than already exists, and the only possible information leakage would be the number of calls processed by each vendor. However, part of the organization's charter would be a secrecy clause, and it may be possible to give assurances of the secrecy of this data by opening the code for inspection to members and using one-way hashes before data insertion. I have faith that these kind of details could be worked out with more discussion in a way that would be mutually acceptable.

Creation of such an entity and database would obviously not solve the problem completely. There is nothing saying that membership would be universal among companies that are candidates for inclusion, nor does it say that only members can accept calls from other members--that is their decision to make independently. I am not a proponent of legally requiring membership in such an organization. However, I think it's a first good step that the industry could take toward preventing further legislation that may be more technically impossible and stifling. Companies that do not join may eventually be seen as less legitimate, and it may be the case that they are not allowed to interconnect with CLID/ANI capabilities (though this certainly remains to be seen, and the refusal of interconnection would be made on an organization-by-organization basis.) Just like many ISPs will not peer with other ASNs if there is no written policy of ingress filtering, membership in this organization may become the "policy" precursor for interconnection.

Anyone wanting further information on this concept may contact me at jtodd@talkplus.com. My company is looking to provide basic funding for the construction of a nonprofit and to participate in the database, but we will only act if others are willing to minimally invest in the experiment. Please forward this message to technical or executive staff of firms that you feel have an interest in keeping their "Phone 2.0" businesses unregulated in this regard. Additionally, I am interested in the LEA perspective here, and it would be useful to hear about the current state of the art and thoughts from law enforcement on the future of these kinds of technical issues.

http://www.linux.com/article.pl?sid=06/10/12/1337224

Now that Slackware 11.0 is out, you may wonder what is the best way to update the distribution. Swaret is an open source project that aims to keep various versions of Slackware up-to-date. I use Swaret and some cron scripts to keep my servers current automatically.

$ cp swaret-1.6.2-noarch-1.tgz.tar swaret-1.6.2-noarch-1.tgz

From there you need to become superuser or log in as root to install the software using the installpkg command:

# installpkg swaret-1.6.2-noarch-1.tgz

Rename the conf file located in the /etc folder:

# cp /etc/swaret.conf.new /etc/swaret.conf

Next, set the version of Slackware you wish to keep on your computer. You can set it to 11.0 or current. Current is the most up-to-date version, and it may be unstable and could pose problems, but it should be easier to upgrade to the next version when it rolls out. I keep some servers on current and others, the ones I consider critical, on 11.0:

# swaret --set VERSION=11.0

Now you can update the list of packages Swaret uses:

# swaret --update

When that command completes successfully you can run the upgrades. You can use the -a switch to automatically install all new updates without being prompted, or use no switch to be prompted for each package update:

# swaret --upgrade

Since version 11.0 has just come out there won't be many updates right away, so don't expect much at first.

You can also use Swaret to install programs that were not installed originally by using this command (replace package-name with the actual name of the package):

# swaret --install package-name

Here is a simple script you can place in one of your cron folders to run Swaret on a regular schedule:

#!/bin/bash
#
#swaret-update.sh
#
# this will download the update files needed to upgrade
#
swaret --update
#
#
# this will update all the packages automatically
#
swaret --upgrade -a
#
# send an email notifying that the update was complete
#
echo "The updates were completed" | mail -s "Swaret Update" username
#
#eof

I have this script in my weekly cron folder under /etc/cron.weekly. Be aware that this will install all the update packages automatically, whether you want them or not.

Slackware 11.0 contains the 2.4.33.3 Linux kernel, 2.6.17.13 in /extra and 2.6.18 in the /testing directory; the default boot option is the dependable 2.4.33.3 kernel, but this time we included more choices and support for 2.6.x kernels.

This Slackware version is by far the most cutting edge ever released, it includes KDE version 3.5.4 (including the Amarok media player), XFCE 4.2.3.2, the latest versions of Firefox and Thunderbird, plus SeaMonkey 1.0.5 (replacing the Mozilla suite). It also includes glibc-2.3.6, gcc-3.4.6, X11R6.9.0 from X.Org, and more!

Due to the overwhelming number of changes in this release, we have added a CHANGES_AND_HINTS.TXT file which contains information on the evolution of slackware-current. This should prove useful for users upgrading to slackware-11.0. To order your copy of Slackware Linux (available on CD-ROMs and DVD this time) or some other Slackware goodies visit our store. You'll be helping to support the continued efforts of the the Slackware Linux Project.

As always, ISO images are available through BitTorrent but you can also download them from any official Slackware Mirror or from these other mirror sites.

Thanks to everyone who helped to make this new release of Slackware possible, the mirror administrators, and to a fine group of friends on irc.oftc.net for their help with Slackware development, this site, and the BitTorrents!

Have fun!

Pat, and the Slackware team

Patrick Volkerding, Slackware's benevolent dictator for life, has 'released' Slackware Linux 11.0 Release Candidate 2. From the changelog: "This is mostly frozen now unless bugs (or irresistible upgrades) come up, so I'll call this update Slackware 11.0 release candidate 2."

http://www.osnews.com/story.php?news_id=15558

I've installed it on a VM, and must say that I've always liked Slackware, and this release didn't disappoint. I'll be looking forward to the actual 11.0 release.

The first approach I took was to establish a transparent squid proxy on my FreeBSD firewall that I have providing DHCP and NAT for my internal network. I added a third NIC to provide these services for my untrusted wireless network. This will also help you to segment and protect your wired LAN.

allow tcp from 192.168.200.0/24 to 192.168.200.1 dst-port 80
fwd 127.0.0.1,3128 tcp from any to any dst-port 80 via rl0
allow ip from any to 255.255.255.255 dst-port 67,68 in via rl0
allow ip from any 67,68 to any out via rl0
allow ip from 192.168.200.0/24 to XXX.XXX.XXX.XXX dst-port 53 in via rl0
allow ip from any to 192.168.200.0/24 out via rl0
deny ip from any to any via rl0

This will basically allow them to obtain a DHCP lease, access the specified DNS servers that I advertised to them in that DHCP lease, access port 80 on the FreeBSD system (where I have a stripped down Apache install serving up my pages), and blocking everything else.

I then use squidGuard with the following config:

src privleged
 {
  ip  192.168.200.1
 }
acl
 {
  privleged
   {
    pass all
   }
  default
   {
    pass local none
    redirect http://192.168.200.1
   }
 }

This allows me to redirect all of their browsing to a single page, I like to play around with that and put in things like this.

I also ran across a post on slashdot that forwarded to this link which provides some quick perl scripts that can be used to invert, or blur images in all webpages that are returned to the user.

http://www.hurtwood.demon.co.uk/Fun/copter.swf