link
Modify /usr/local/etc/sshd_config to include the following lines (your environment may vary):
# Use the following line to *replace* any existing ‘Subsystem’ line
Subsystem sftp internal-sftp
# These lines must appear at the *end* of sshd_config
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
This means that all users you add to the ‘sftponly’ group will be chroot’d to their home directory, and will only be able to run the internal SFTP process.
Create a new user group to add users to (this determines whether they are chroot’d or not), using groupadd sftponly.
Now, configure your users’ accounts as follows (don’t forget to do this with new users as well):
* Set their group (usermod -g) to sftponly (the group you created in the previous step)
* Set their shell (usermod -s) to /bin/false (to deny them shell access)
* Set their home directory (usermod -d) as you prefer
* Important (OpenSSH tests for this condition): ensure their home directory is owned by root, and is not writable by any other user or group. This must also be the case for each directory in the path up to the root of your system.
* Ensure the default UMASK is set appropriately – I found my users got confused if their files didn’t automatically set themselves to rwxr-xr-x (755), so I added CMASK=022 to /etc/default/login
Test the setup (you will probably need to HUP your SSH daemon first, or start it up if it isn’t already). Use sftp username@hostname.org and make sure you can’t change directory out of the chroot’d environment. Also check access is denied when using ssh
Posted by admin on September 25, 2009 – 1:29 pm
Filed under WEB-DEV-LOG
Tagged as
supports SFTP
perk regular expression to delete blank lines ^\s*[\r\n]+
Posted by admin on September 21, 2009 – 5:22 pm
Filed under WEB-DEV-LOG
Tagged as
AltaVista was publicly launched as an internet search engine on 15 December 1995 at altavista.digital.com.[3][4]
At launch, the service had two innovations which set it ahead of the other search engines. It used a fast, multi-threaded crawler (Scooter) which could cover a lot more Web pages than were believed to exist at the time and an efficient search back-end running on advanced hardware.
http://en.wikipedia.org/wiki/AltaVista
Posted by admin on September 21, 2009 – 5:12 pm
Filed under WEB-DEV-LOG
Tagged as
History
The FTP archive on gatekeeper.dec.com, later to become gatekeeper.research.compaq.com, first went on-line in the late 1980′s. It was assembled from spare parts and brought to life by Paul Vixie. Located at Digital Equipment Corporation’s Western Research Laboratory (DECWRL) in Palo Alto, California, it was maintained by a handful of volunteers from Digital Corporate Research. The spare parts were eventually replaced with production hardware.
In its heyday, gatekeeper was a prominent Internet FTP site. Just about any public domain software package you wanted or needed could be found on gatekeeper. One of gatekeepers’ primary functions was to give Digital software developers, living on the DECNET based internal corporate network, access to public domain software available from the Internet. (The Digital internal DECNET host, DECPA::, mounted the gatekeeper FTP archive via NFS.) Gatekeeper was also used by Digital product groups to provide software updates and patches to Internet customers.
Today
Over the years, acqusitions, mergers, and business needs have changed the role of gatekeeper. Early in 2008, gatekeeper.dec.com and gatekeeper.research.compaq.com were redirected to apotheca.hpl.hp.com, a shiny new server at HP Labs in Palo Alto, California. ftp.hpl.hp.com is also directed to apotheca.
Apotheca doesn’t mirror any of the public domain software repositories that were mirrored on gatekeeper. Now days, there’s plenty of Internet sites that do a fine job of serving those bits. This is why you’ll find ~ftp/pub rather sparce, compared to what you use to find on the old gatekeeper.
The legacy content from the Digital and Compaq research labs is available in ~ftp/gatekeeper/ .
Richard Schedler
Gatekeeper Archive Administrator 1993-2007
Posted by admin on September 20, 2009 – 5:49 pm
Filed under WEB-DEV-LOG
Tagged as
# Pop. 453. In Cairo T., Timiskaming Dist. on a tributary of the Montreal R., 2 km. from its confluence and Hwys 66 and 566, 56 km. SW of Kirkland Lake.
# First called Dokis Trading Post, the post office was established as Matachewan in 1935. The derivative Ojibwa word matadjiwan means ”the current (of the river) is heard.’
Posted by admin on September 18, 2009 – 3:35 am
Filed under WEB-DEV-LOG
Tagged as
http://highscalability.com/
Sat, 09/12/2009 – 16:31 — General Chicken
A user named Apathy in this thread on how Reddit scales some of their features, shares some advice he learned while working at Google and other major companies.
To be fair, I [Apathy] was working at Google at the time, and every job I held between 1995 and 2005 involved at least one of the largest websites on the planet. I didn’t come up with any of these ideas, just watched other smart people I worked with who knew what they were doing and found (or wrote) tools that did the same things. But the theme is always the same:
Cache everything you can and store the rest in some sort of database (not necessarily relational and not necessarily centralized).
How do you go about applying this strategy?
Cache everything that doesn’t change rapidly. Most of the time you don’t have to hit the database for anything other than checking whether the users’ new message count has transitioned from 0 to (1 or more).
Cache everything–templates, user message status, the front page components–and hit the database once a minute or so to update the front page, forums, etc. This was sufficient to handle a site with a million hits a day on a couple of servers. The site was sold for $100K.
Cache the users’ subreddits. Blow out the cache on update.
Cache the top links per subreddit. Blow out cache on update.
Combine the previous two steps to generate a menu from cached blocks.
Cache the last links. Blow out the cache on each outlink click.
Cache the user’s friends. Append 3 characters to their name.
Cache the user’s karma. Blow out on up/down vote.
Filter via conditional formatting, CSS, and an ajax update.
Decouple selection/ranking algorithm(s) from display.
Use Google or something like Xapian or Lucene for search.
Cache “for as long as memcached will stay up.” That depends on how many instances you’re running, what else is running, how stable the Python memcached hooks are, etc.
The golden rule of website engineering is that you don’t try to enforce partial ordering simultaneously with your updates.
When running a search engine operate the crawler separately from the indexer.
Ranking scores are used as necessary from the index, usually cached for popular queries.
Re-rank popular subreddits or the front page once a minute. Tabulate votes and pump them through the ranker.
Cache the top 100 per subreddit. Then cache numbers 100-200 when someone bothers to visit the 5th page of a subreddit, etc.
For less-popular subreddits, you cache the results until an update comes in.
With enough horsepower and common sense, almost any volume of data can be managed, just not in realtime.
Never ever mix your reads and writes if you can help it.
Merge all the normalized rankings and cache the output every minute or so. This avoids thousands of queries per second just for personalization.
It’s a lot cheaper to merge cached lists than build them from scratch. This delays the crushing read/write bottleneck at the database. But you have to write the code.
Layering caches is a clasisc strategy for milking your servers as much as possilbe. First look for an exact match. If that’s not found, look for the components and build an exact match.
The majority of traffic on almost all websites comes from the default, un-logged-in front page or from random forum/comment/result pages. Make sure those are cached as much as possible.. If one or more of the components aren’t found, regenerate those from the DB (now it’s cached!) and proceed. Never hit the database unless you have to.
You (almost) always have to hit the database on writes. The key is to avoid hitting it for reads until you’re forced to do so.
FROM HERE
Posted by admin on September 15, 2009 – 4:40 pm
Filed under WEB-DEV-LOG
Tagged as
/var/db/mysql/my.cnf
/usr/local/share/mysql/my-medium.cnf
Posted by admin on September 15, 2009 – 4:11 pm
Filed under WEB-DEV-LOG
Tagged as
1.6. How can I keep stable versions of most packages?
That’s easy! Just add the following line to /etc/apt/apt.conf.d/70debconf:
APT::Default-Release “stable”;
1.9. How can I downgrade my system back to stable
One might think that apt-get dist-upgrade/stable would work, but no: the system informs you that you already have the most recent versions of all packages. (And I want to cry out, “I know that, you moron. That’s why I’m trying to downgrade to older versions.”)
However! Turns out that it’s easy! Just create the file /etc/apt/preferences with the folllwing contents:
Package: *
Pin: release a=stable
Pin-Priority: 1001
and run apt-get dist-upgrade.
It all seems so obvious now. It makes me feel ashamed that I didn’t just guess that I had to create this brand new configuration file that I’d never needed before instead of editing either of the two I’ve already had to mess with.
Once you’ve done this, though, life is sweet. The upgrade process (really a downgrade) trundles merrily along, until -
1.10. How can I fix “also in package” errors?
error processing /hulk/archives/debian-3.0/cd2/pool/main/libp/libpaper/libpaperg_1.1.8_i386.deb (–unpack):
trying to overwrite `/usr/lib/libpaper.so.1.1.2′, which is also in package libpaper1
That’s easy! Just use:
apt-get -f install
apt-get dist-upgrade # again
Of course!
FROM HERE
Posted by admin on September 15, 2009 – 10:41 am
Filed under WEB-DEV-LOG
Tagged as
Package: initscripts
Version: 2.86.ds1-1
Severity: normal
File: /etc/init.d/checkfs.sh
when check a nonexistent fs, boot halt,must press CONTROL-D continue
remote or a no display system,....
change checkfs.sh, after a little ,continue the boot.
patch:
--- /etc/init.d/checkfs.sh.orig 2005-06-06 13:40:08.000000000 +0800
+++ /etc/init.d/checkfs.sh 2005-06-07 09:29:56.000000000 +0800
@@ -39,7 +39,7 @@
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
- /sbin/sulogin $CONSOLE
+ /sbin/sulogin -t 100 $CONSOLE
fi
fi
rm -f /fastboot /forcefsck
