From james.gates@sun.com Wed Feb 20 09:11:40 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KHBe8D007516 for ; Wed, 20 Feb 2008 09:11:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KHBdUi019308 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 20 Feb 2008 09:11:39 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWJ0001FRRFVT00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 10:11:39 -0700 (MST) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWJ00GTRRRDP880@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 10:11:38 -0700 (MST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KHBbCF029103 for ; Wed, 20 Feb 2008 17:11:37 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-65-89.East.Sun.COM [129.150.65.89]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m1KHBJX0028327 for ; Wed, 20 Feb 2008 17:11:28 +0000 (GMT) Date: Wed, 20 Feb 2008 12:10:45 -0500 From: James Gates Subject: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris To: lsarc-ext@sun.com Message-id: <47BC5F15.3050205@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7r7BsHb4NjKKo/dNZ779Ow)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 10481 This is a multi-part message in MIME format. --Boundary_(ID_7r7BsHb4NjKKo/dNZ779Ow) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I am sponsoring this fast-track on behalf of Roy Lyseng. The timer expires 02/28/08. Attached is a copy of the proposal, which can also be found in the case directory. DTrace probe definitions are in the materials directory. I believe it qualifies for micro/patch release binding (although the project team only intend to integrate into Nevada). I have also discussed interface taxonomy with Roy, and arrived at a combination of both volatile & uncommitted (although there is still some uncertainty regarding how much we can rely on the community to maintain the stability of the interfaces). --Boundary_(ID_7r7BsHb4NjKKo/dNZ779Ow) Content-type: text/plain; name=memcached_1.2.5_1pager.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=memcached_1.2.5_1pager.txt Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: memcached 1.2.5 to be included in OpenSolaris 1.2. Name of Document Author/Supplier: Roy Lyseng 1.3. Date of This Document: 02/20/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Webstack 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: erlend.dahl@sun.com 1.5.2. Responsible Engineer: roy.lyseng@sun.com 1.5.4. Interest List: memcached-interest@sun.com 2. Project Summary 2.1. Project Description: Update memcached in OpenSolaris from version 1.2.2 to 1.2.5. Add Java API version 2.0. Add C API libmemcached version 0.16. Remove C API libmemcache version 1.4.0. memcached is performance enhanced for multicore computers. Add Dtrace probes to memcached. Add 64-bit version of memcached. Refer also ARC case LSARC/2007/385 that added memcached 1.2.2. 2.2. Risks and Assumptions: Replacing libmemcache with libmemcached is a risk if somebody depend on libmemcache. However, we think the community for this API is small. 3. Business Summary 3.1. Problem Area: Increase performance on Sun hardware. Increase supported cache size beyond limit enforced by 32-bit arch. Supply a richer set of client interfaces. Remove interfaces that are not actively maintained. 3.6. How will you know when you are done?: memcached on Niagara is competitive to other offerings. 4. Technical Description: 4.1 Details The update to the memcached daemon is mostly a version upgrade. An additional option is made to enhance large memory utilization. The Java API was described in LSARC/2007/385, but was not included at that time due to missing OSR approval (time constrained). The libmemcached C API includes a set of binary utility programs. These are all placed in the /usr/memcached/bin directory and are given a Volatile stability classification. They are only meant for ad-hoc use. Their man pages are placed in /usr/memcached/share/man. The library exists in 32 and 64 bit versions, but the utilities are 32 bit only. Dtrace probes are described in attached memcached_dtrace.d. 4.5. Interfaces: Id Interface name Stability Comment ------------------------------------------------------------------ E10 libmemcache C API Volatile Removed E18 libmemcached C API Uncommitted New in Solaris E20 daemon command line Uncommitted New option: -L enable large pages E27 Dtrace probes Uncommitted Probes added E31 memcat Volatile libmemcached utility E32 memcp Volatile libmemcached utility E33 memerror Volatile libmemcached utility E34 memflush Volatile libmemcached utility E35 memrm Volatile libmemcached utility E36 memslap Volatile libmemcached utility E37 memstat Volatile libmemcached utility 4.6. Doc Impact: Need man pages for new libmemcached C API Man page update for command line options must be updated for -L 4.7. Admin/Config Impact: Only if application tuning is required. 4.8. HA Impact: None 4.9. I18N/L10N Impact: None 4.10. Packaging & Delivery: New packages are added for C API and Java API, see appendix. 4.11. Security Impact: No changes. 4.12. Dependencies: No changes. 5. Reference Documents: 6. Resources and Schedule: 6.1. Projected Availability: CY 2008 - Q1 6.2. Cost of Effort: 1.5 persons in engineering 1 person in QE/QA 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.4.7. Target RTI Date/Release: SNV build 86 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris Packages SUNWmemcached - [usr] Server package SUNWmemcachedr - [root] SMF files SUNWlibmemcached - [usr] libmemcached C API SUNWmemcached-java - [usr] Memcached Java API File structure (SUNWmemcached) /usr/lib/memcached /usr/lib//memcached /usr/share/man/man1m/memcached.1m File structure (SUNWmemcachedr) /lib/svc/method/memcached /var/svc/manifest/application/database/memcached.xml File structure (SUNWmemcached-java) /usr/share/lib/java/java_memcached_release_2.0.jar /usr/share/lib/java/javadoc/memcached-java/* File structure (SUNWlibmemcached) /usr/lib/libmemcached.so.2.0.0 /usr/lib/libmemcached.so.2 -> /usr/lib/libmemcached.so.2.0.0 /usr/lib/libmemcached.so -> /usr/lib/libmemcached.so.2.0.0 /usr/lib//libmemcached.so.2.0.0 /usr/lib//libmemcached.so.2 -> /usr/lib//libmemcached.so.2.0.0 /usr/lib//libmemcached.so -> /usr/lib//libmemcached.so.2.0.0 /usr/include/libmemcached/memcached.h /usr/memcached/bin/memcat /usr/memcached/bin/memcp /usr/memcached/bin/memerror /usr/memcached/bin/memflush /usr/memcached/bin/memrm /usr/memcached/bin/memslap /usr/memcached/bin/memstat /usr/memcached/share/man/man1/memcat.1 /usr/memcached/share/man/man1/memcp.1 /usr/memcached/share/man/man1/memerror.1 /usr/memcached/share/man/man1/memflush.1 /usr/memcached/share/man/man1/memrm.1 /usr/memcached/share/man/man1/memslap.1 /usr/memcached/share/man/man1/memstat.1 /usr/share/man/man3libmemcached/libmemcached.3libmemcached /usr/share/man/man3libmemcached/libmemcached_examples.3libmemcached /usr/share/man/man3libmemcached/memcached_add.3libmemcached /usr/share/man/man3libmemcached/memcached_add_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_append.3libmemcached /usr/share/man/man3libmemcached/memcached_append_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_behavior_get.3libmemcached /usr/share/man/man3libmemcached/memcached_behavior_set.3libmemcached /usr/share/man/man3libmemcached/memcached_callback_get.3libmemcached /usr/share/man/man3libmemcached/memcached_callback_set.3libmemcached /usr/share/man/man3libmemcached/memcached_cas.3libmemcached /usr/share/man/man3libmemcached/memcached_cas_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_clone.3libmemcached /usr/share/man/man3libmemcached/memcached_create.3libmemcached /usr/share/man/man3libmemcached/memcached_decrement.3libmemcached /usr/share/man/man3libmemcached/memcached_delete.3libmemcached /usr/share/man/man3libmemcached/memcached_delete_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch_execute.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch_result.3libmemcached /usr/share/man/man3libmemcached/memcached_free.3libmemcached /usr/share/man/man3libmemcached/memcached_get.3libmemcached /usr/share/man/man3libmemcached/memcached_get_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_increment.3libmemcached /usr/share/man/man3libmemcached/memcached_lib_version.3libmemcached /usr/share/man/man3libmemcached/memcached_mget.3libmemcached /usr/share/man/man3libmemcached/memcached_mget_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_prepend.3libmemcached /usr/share/man/man3libmemcached/memcached_prepend_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_quit.3libmemcached /usr/share/man/man3libmemcached/memcached_replace.3libmemcached /usr/share/man/man3libmemcached/memcached_replace_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_server_add.3libmemcached /usr/share/man/man3libmemcached/memcached_server_count.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_append.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_count.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_free.3libmemcached /usr/share/man/man3libmemcached/memcached_server_push.3libmemcached /usr/share/man/man3libmemcached/memcached_servers_parse.3libmemcached /usr/share/man/man3libmemcached/memcached_set.3libmemcached /usr/share/man/man3libmemcached/memcached_set_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_stat.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_get_keys.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_get_value.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_servername.3libmemcached /usr/share/man/man3libmemcached/memcached_strerror.3libmemcached /usr/share/man/man3libmemcached/memcached_verbosity.3libmemcached /usr/share/man/man3libmemcached/memcached_version.3libmemcached is replaced with sparcv9 for Sparc 64 bit architecture and with amd64 for AMD 64 bit architecture. --Boundary_(ID_7r7BsHb4NjKKo/dNZ779Ow)-- From dan.mick@sun.com Wed Feb 20 12:28:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KKS7kt028858 for ; Wed, 20 Feb 2008 12:28:08 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1KKRpWZ012161 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 21 Feb 2008 04:28:06 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK00F1H0UQLF00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 13:28:02 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK009360UQ4E90@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 13:28:02 -0700 (MST) Received: from [129.150.18.164] (vpn-129-150-18-164.SFBay.Sun.COM [129.150.18.164]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KKS0j4005870; Wed, 20 Feb 2008 12:28:00 -0800 (PST) Date: Wed, 20 Feb 2008 12:27:54 -0800 From: Dan Mick Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BC5F15.3050205@sun.com> To: James Gates Cc: lsarc-ext@sun.com Message-id: <47BC8D4A.2000804@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1044 Shouldn't there be something in the proposal that documents what memcached/libmemcache actually *do*? (I mean, I get that it involves caching in memory, but so does most everything on a computer.) James Gates wrote: > I am sponsoring this fast-track on behalf of Roy Lyseng. The timer > expires 02/28/08. Attached is a copy of the proposal, which can also be > found in the case directory. DTrace probe definitions are in the > materials directory. > > I believe it qualifies for micro/patch release binding (although the > project team only intend to integrate into Nevada). I have also > discussed interface taxonomy with Roy, and arrived at a combination of > both volatile & uncommitted (although there is still some uncertainty > regarding how much we can rely on the community to maintain the > stability of the interfaces). > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From james.gates@sun.com Wed Feb 20 13:13:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KLDOwH002677 for ; Wed, 20 Feb 2008 13:13:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1KLDJSj029582 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 21 Feb 2008 05:13:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK009032YAX000@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 13:13:22 -0800 (PST) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK0025V2Y9C1B0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 13:13:21 -0800 (PST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KLDIne011114; Wed, 20 Feb 2008 21:13:18 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-65-89.East.Sun.COM [129.150.65.89]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m1KLD06W002184; Wed, 20 Feb 2008 21:13:08 +0000 (GMT) Date: Wed, 20 Feb 2008 16:12:27 -0500 From: James Gates Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BC8D4A.2000804@sun.com> To: Dan Mick Cc: lsarc-ext@sun.com Message-id: <47BC97BB.8020607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 1291 I have asked Roy to provide a one paragraph summary that I can add to the 1pager. But in the meantime, you can read http://www.danga.com/memcached/ and http://en.wikipedia.org/wiki/Memcached Dan Mick wrote: > Shouldn't there be something in the proposal that documents what > memcached/libmemcache actually *do*? > > (I mean, I get that it involves caching in memory, but so does most > everything on a computer.) > > James Gates wrote: > >> I am sponsoring this fast-track on behalf of Roy Lyseng. The timer >> expires 02/28/08. Attached is a copy of the proposal, which can also >> be found in the case directory. DTrace probe definitions are in the >> materials directory. >> >> I believe it qualifies for micro/patch release binding (although the >> project team only intend to integrate into Nevada). I have also >> discussed interface taxonomy with Roy, and arrived at a combination of >> both volatile & uncommitted (although there is still some uncertainty >> regarding how much we can rely on the community to maintain the >> stability of the interfaces). >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > > From David.Comay@sun.com Wed Feb 20 14:19:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KMJlmP008181 for ; Wed, 20 Feb 2008 14:19:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KMJiKJ017493 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Wed, 20 Feb 2008 15:19:47 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK00C1H60YPB00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 20 Feb 2008 14:19:46 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK0026V60YC4E0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 20 Feb 2008 14:19:46 -0800 (PST) Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KMJiUs015828; Wed, 20 Feb 2008 14:19:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KMJihP001882; Wed, 20 Feb 2008 14:19:44 -0800 (PST) Date: Wed, 20 Feb 2008 14:19:44 -0800 (PST) From: David.Comay@sun.com Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BC97BB.8020607@sun.com> Sender: David.Comay@sun.com To: James Gates Cc: Dan Mick , lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> <47BC97BB.8020607@sun.com> Status: RO Content-Length: 420 > I have asked Roy to provide a one paragraph summary that I can add to > the 1pager. But in the meantime, you can read > http://www.danga.com/memcached/ and http://en.wikipedia.org/wiki/Memcached Also as this is a version update to a previous case, you can find out more about memcached by looking at the earlier case, LSARC/2007/385. In particular, LSARC/2007/385/commitment.materials.final/questionnaire.txt dsc From james.gates@sun.com Thu Feb 21 09:06:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LH6gi7016548 for ; Thu, 21 Feb 2008 09:06:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LH6eg7016793 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 21 Feb 2008 17:06:41 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWL00E16M725O00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 21 Feb 2008 09:06:38 -0800 (PST) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWL007P6M70F3C0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 21 Feb 2008 09:06:37 -0800 (PST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LH6Y2F014553; Thu, 21 Feb 2008 17:06:34 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-65-75.East.Sun.COM [129.150.65.75]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m1LH6F46018358; Thu, 21 Feb 2008 17:06:23 +0000 (GMT) Date: Thu, 21 Feb 2008 12:05:41 -0500 From: James Gates Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BCCD03.9060108@sun.com> To: Dan Mick Cc: lsarc-ext@sun.com Message-id: <47BDAF65.1030802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> <47BC97BB.8020607@sun.com> <47BCCD03.9060108@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 2326 I've added the following summary to the details section of the 1pager: memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. Danga Interactive developed memcached to enhance the speed of LiveJournal.com, a site which was already doing 20 million+ dynamic page views per day for 1 million users with a bunch of webservers and a bunch of database servers. memcached dropped the database load to almost nothing, yielding faster page load times for users, better resource utilization, and faster access to the databases on a memcache miss. How it Works First, you start up the memcached daemon on as many spare machines as you have. The daemon has no configuration file, just a few command line options, only 3 or 4 of which you'll likely use: # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 This starts memcached up as a daemon, using 2GB of memory, and listening on IP 10.0.0.40, port 11211. Because a 32-bit process can only address 4GB of virtual memory (usually significantly less, depending on your operating system), if you have a 32-bit server with 4-64GB of memory using PAE you can just run multiple processes on the machine, each using 2 or 3GB of memory. Now, in your application, wherever you go to do a database query, first check the memcache. If the memcache returns an undefined object, then go to the database, get what you're looking for, and put it in the memcache. Dan Mick wrote: > David.Comay@Sun.COM wrote: > >>> I have asked Roy to provide a one paragraph summary that I can add to >>> the 1pager. But in the meantime, you can read >>> http://www.danga.com/memcached/ and >>> http://en.wikipedia.org/wiki/Memcached >> >> >> Also as this is a version update to a previous case, you can find out >> more about memcached by looking at the earlier case, LSARC/2007/385. >> In particular, >> >> LSARC/2007/385/commitment.materials.final/questionnaire.txt >> >> dsc > > > yes, although one sentence in the current case is pretty low-cost. From dan.mick@sun.com Thu Feb 21 12:33:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LKXY64027447 for ; Thu, 21 Feb 2008 12:33:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LKXVa8017819 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 21 Feb 2008 20:33:33 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWL00E01VRWAN00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 21 Feb 2008 13:33:32 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWL0015XVRVH2A0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 21 Feb 2008 13:33:32 -0700 (MST) Received: from [129.150.18.136] (vpn-129-150-18-136.SFBay.Sun.COM [129.150.18.136]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LKXTEW020665; Thu, 21 Feb 2008 12:33:30 -0800 (PST) Date: Thu, 21 Feb 2008 12:33:23 -0800 From: Dan Mick Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BDAF65.1030802@sun.com> To: James Gates Cc: lsarc-ext@sun.com Message-id: <47BDE013.7030301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> <47BC97BB.8020607@sun.com> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2446 That's a lot, and excellent; thanks. James Gates wrote: > I've added the following summary to the details section of the 1pager: > > memcached is a high-performance, distributed memory object caching > system, generic in nature, but intended for use in speeding up > dynamic web applications by alleviating database load. > > Danga Interactive developed memcached to enhance the speed of > LiveJournal.com, a site which was already doing 20 million+ > dynamic page views per day for 1 million users with a bunch of > webservers and a bunch of database servers. memcached dropped the > database load to almost nothing, yielding faster page load times > for users, better resource utilization, and faster access to the > databases on a memcache miss. > > How it Works > > First, you start up the memcached daemon on as many spare machines > as you have. The daemon has no configuration file, just a few > command line options, only 3 or 4 of which you'll likely use: > > # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 > > This starts memcached up as a daemon, using 2GB of memory, and > listening on IP 10.0.0.40, port 11211. Because a 32-bit process > can only address 4GB of virtual memory (usually significantly > less, depending on your operating system), if you have a 32-bit > server with 4-64GB of memory using PAE you can just run multiple > processes on the machine, each using 2 or 3GB of memory. > > Now, in your application, wherever you go to do a database query, > first check the memcache. If the memcache returns an undefined > object, then go to the database, get what you're looking for, and > put it in the memcache. > > > Dan Mick wrote: >> David.Comay@Sun.COM wrote: >> >>>> I have asked Roy to provide a one paragraph summary that I can add to >>>> the 1pager. But in the meantime, you can read >>>> http://www.danga.com/memcached/ and >>>> http://en.wikipedia.org/wiki/Memcached >>> >>> >>> Also as this is a version update to a previous case, you can find out >>> more about memcached by looking at the earlier case, LSARC/2007/385. >>> In particular, >>> >>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>> >>> dsc >> >> >> yes, although one sentence in the current case is pretty low-cost. From Lloyd.Chambers@sun.com Fri Feb 22 11:04:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1MJ4FcN010506 for ; Fri, 22 Feb 2008 11:04:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1MJ4AMn005428 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 22 Feb 2008 19:04:14 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWN0080BMB0VM00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 22 Feb 2008 11:04:12 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWN0089QMAZR600@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 22 Feb 2008 11:04:11 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1MJ4Ba7008031 for ; Fri, 22 Feb 2008 11:04:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWN00B01M4S5600@fe-sfbay-10.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 22 Feb 2008 11:04:11 -0800 (PST) Received: from [192.168.1.8] ([129.150.18.151]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWN000CDMARWS30@fe-sfbay-10.sun.com>; Fri, 22 Feb 2008 11:04:10 -0800 (PST) Date: Fri, 22 Feb 2008 11:04:10 -0800 From: Lloyd L Chambers Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BDAF65.1030802@sun.com> Sender: Lloyd.Chambers@sun.com To: James Gates Cc: Dan Mick , lsarc-ext@sun.com Message-id: <29078BB1-91C9-401B-96C7-AF9AAE988E96@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> <47BC97BB.8020607@sun.com> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> Status: RO Content-Length: 2803 Sounds terrific! llc01 Are there any security issues with the memcached daemons, given that they're listening on ports? If I understand correctly, 10.0.0.x is a LAN address, which exposes the IP only to the local subnet. Still, can you say if there are concerns here? Lloyd Chambers LSARC On Feb 21, 2008, at 9:05 AM, James Gates wrote: > I've added the following summary to the details section of the 1pager: > > memcached is a high-performance, distributed memory object > caching > system, generic in nature, but intended for use in speeding up > dynamic web applications by alleviating database load. > > Danga Interactive developed memcached to enhance the speed of > LiveJournal.com, a site which was already doing 20 million+ > dynamic page views per day for 1 million users with a bunch of > webservers and a bunch of database servers. memcached dropped > the > database load to almost nothing, yielding faster page load > times > for users, better resource utilization, and faster access to > the > databases on a memcache miss. > > How it Works > > First, you start up the memcached daemon on as many spare > machines > as you have. The daemon has no configuration file, just a few > command line options, only 3 or 4 of which you'll likely use: > > # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 > > This starts memcached up as a daemon, using 2GB of memory, and > listening on IP 10.0.0.40, port 11211. Because a 32-bit process > can only address 4GB of virtual memory (usually significantly > less, depending on your operating system), if you have a 32-bit > server with 4-64GB of memory using PAE you can just run > multiple > processes on the machine, each using 2 or 3GB of memory. > > Now, in your application, wherever you go to do a database > query, > first check the memcache. If the memcache returns an undefined > object, then go to the database, get what you're looking for, > and > put it in the memcache. > > > Dan Mick wrote: >> David.Comay@Sun.COM wrote: >>>> I have asked Roy to provide a one paragraph summary that I can >>>> add to >>>> the 1pager. But in the meantime, you can read >>>> http://www.danga.com/memcached/ and http://en.wikipedia.org/wiki/Memcached >>> >>> >>> Also as this is a version update to a previous case, you can find >>> out >>> more about memcached by looking at the earlier case, LSARC/2007/385. >>> In particular, >>> >>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>> >>> dsc >> yes, although one sentence in the current case is pretty low-cost. --- Lloyd L Chambers lloyd.chambers@sun.com Sun Microsystems, Inc From Roy.Lyseng@sun.com Mon Feb 25 02:24:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PAOSER003831 for ; Mon, 25 Feb 2008 02:24:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1PAOPdD012716 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Feb 2008 10:24:27 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWS00435I8PYZ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 02:24:26 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWS00DVWI8HMPB0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 02:24:18 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1PAOHtB010569 for ; Mon, 25 Feb 2008 10:24:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWS00H01I7GTQ00@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 10:24:17 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWS00GKFI7ADZ00@fe-emea-09.sun.com>; Mon, 25 Feb 2008 10:23:34 +0000 (GMT) Date: Mon, 25 Feb 2008 11:20:54 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47BF1CFB.4040004@sun.com> Sender: Roy.Lyseng@sun.com To: James Gates , Lloyd Chambers , lsarc-ext@sun.com Message-id: <47C29686.9090403@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 5693 Hi Lloyd, it is indeed possible to configure memcached to listen to local addresses only. If the administrator decides to configure memcached to listen on a publicly available address, a security hole may be opened. There was a substantial discussion on Memcached and security during the first ARC case (LSARC/2007/385). These issues were raised during that case (followed by my responses): Terrence Miller wrote: > tm-1 Can the client and server be on the same machine. If so, > can that system be configured to not accept requests > from the network. The server may be configured to listen on a user-defined port. A firewall may be configured to block that port. You can also configure memcached to listen on a specific interface, in particular the localhost interface. > > tm-2 Can an attack on the server cause it to overload its host > machine. I think that will be very difficult. Processing overhead is very light, it is actually more probable that the attacker will saturate the network. Besides, the memcached server is usually part of a backend system, residing on the same level as a backend database server and having an application server or web server in front. An attacker may attempt to fill the cache with garbage objects that invalidate the "valid" objects. This may become a problem if the attacker gets network access to the memcached server. > > tm-3 Does your documentation state the requirement for protecting > any network connecting clients to server. We do not provide documentation in addition to that provided by the community. > > tm-4 How hard is it to write a firewall rule that blocks all > memcached traffic. The server is usually listening on a single TCP socket, so it should be easy to write a firewall rule that blocks the associated port. As an option, the memcached server may also listen on a UDP socket, but this can also easily be protected. > > tm-5 Will the firewall requirements change with new releases. Impossible to say. The community designs and implements changes to the product. We ended up adding information to release notes that warn administrators about potential security holes when listening on publicly available ports. Hope this answers your questions, Roy James Gates wrote: > > > -------- Original Message -------- > Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris > Date: Fri, 22 Feb 2008 11:04:10 -0800 > From: Lloyd L Chambers > To: James Gates > CC: Dan Mick , lsarc-ext@Sun.COM > References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> > <47BC97BB.8020607@sun.com> > <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> > > Sounds terrific! > > llc01 Are there any security issues with the memcached daemons, given > that they're listening on ports? If I understand correctly, 10.0.0.x > is a LAN address, which exposes the IP only to the local subnet. > Still, can you say if there are concerns here? > > Lloyd Chambers > LSARC > > > On Feb 21, 2008, at 9:05 AM, James Gates wrote: > >> I've added the following summary to the details section of the 1pager: >> >> memcached is a high-performance, distributed memory object >> caching >> system, generic in nature, but intended for use in speeding up >> dynamic web applications by alleviating database load. >> >> Danga Interactive developed memcached to enhance the speed of >> LiveJournal.com, a site which was already doing 20 million+ >> dynamic page views per day for 1 million users with a bunch of >> webservers and a bunch of database servers. memcached dropped the >> database load to almost nothing, yielding faster page load times >> for users, better resource utilization, and faster access to the >> databases on a memcache miss. >> >> How it Works >> >> First, you start up the memcached daemon on as many spare >> machines >> as you have. The daemon has no configuration file, just a few >> command line options, only 3 or 4 of which you'll likely use: >> >> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >> >> This starts memcached up as a daemon, using 2GB of memory, and >> listening on IP 10.0.0.40, port 11211. Because a 32-bit process >> can only address 4GB of virtual memory (usually significantly >> less, depending on your operating system), if you have a 32-bit >> server with 4-64GB of memory using PAE you can just run multiple >> processes on the machine, each using 2 or 3GB of memory. >> >> Now, in your application, wherever you go to do a database query, >> first check the memcache. If the memcache returns an undefined >> object, then go to the database, get what you're looking for, and >> put it in the memcache. >> >> >> Dan Mick wrote: >>> David.Comay@Sun.COM wrote: >>>>> I have asked Roy to provide a one paragraph summary that I can add to >>>>> the 1pager. But in the meantime, you can read >>>>> http://www.danga.com/memcached/ and >>>>> http://en.wikipedia.org/wiki/Memcached >>>> >>>> >>>> Also as this is a version update to a previous case, you can find out >>>> more about memcached by looking at the earlier case, LSARC/2007/385. >>>> In particular, >>>> >>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>> >>>> dsc >>> yes, although one sentence in the current case is pretty low-cost. > > --- > Lloyd L Chambers > lloyd.chambers@sun.com > Sun Microsystems, Inc > > > From Lloyd.Chambers@sun.com Mon Feb 25 11:08:35 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PJ8ZPP020691 for ; Mon, 25 Feb 2008 11:08:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1PJ8ZML019303 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Feb 2008 11:08:35 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT003236HVKJ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 11:08:19 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT003FE6HUBR00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 11:08:18 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1PJ8Ihp028871 for ; Mon, 25 Feb 2008 11:08:18 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00G0161QZD00@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 11:08:18 -0800 (PST) Received: from [192.168.1.8] (diglloyd.com [208.65.183.162]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00HLB6HPOZ10@fe-sfbay-09.sun.com>; Mon, 25 Feb 2008 11:08:13 -0800 (PST) Date: Mon, 25 Feb 2008 11:08:12 -0800 From: Lloyd L Chambers Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C29686.9090403@sun.com> Sender: Lloyd.Chambers@sun.com To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> Status: RO Content-Length: 6125 Roy, Thanks. Does memcached issue a warning in the log if it starts listening on ports at risk? Lloyd On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: > Hi Lloyd, > > it is indeed possible to configure memcached to listen to local > addresses only. If the administrator decides to configure memcached > to listen on a publicly available address, a security hole may be > opened. > > There was a substantial discussion on Memcached and security during > the first ARC case (LSARC/2007/385). > > These issues were raised during that case (followed by my responses): > > Terrence Miller wrote: > > tm-1 Can the client and server be on the same machine. If so, > > can that system be configured to not accept requests > > from the network. > > The server may be configured to listen on a user-defined port. A > firewall may be configured to block that port. > > You can also configure memcached to listen on a specific interface, in > particular the localhost interface. > > > > tm-2 Can an attack on the server cause it to overload its host > > machine. > > I think that will be very difficult. Processing overhead is very > light, > it is actually more probable that the attacker will saturate the > network. Besides, the memcached server is usually part of a backend > system, residing on the same level as a backend database server and > having an application server or web server in front. > > An attacker may attempt to fill the cache with garbage objects that > invalidate the "valid" objects. This may become a problem if the > attacker gets network access to the memcached server. > > > > tm-3 Does your documentation state the requirement for protecting > > any network connecting clients to server. > > We do not provide documentation in addition to that provided by the > community. > > > > tm-4 How hard is it to write a firewall rule that blocks all > > memcached traffic. > > The server is usually listening on a single TCP socket, so it should > be > easy to write a firewall rule that blocks the associated port. As an > option, the memcached server may also listen on a UDP socket, but this > can also easily be protected. > > > > tm-5 Will the firewall requirements change with new releases. > > Impossible to say. The community designs and implements changes to the > product. > > We ended up adding information to release notes that warn > administrators about potential security holes when listening on > publicly available ports. > > Hope this answers your questions, > Roy > > James Gates wrote: >> -------- Original Message -------- >> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >> OpenSolaris >> Date: Fri, 22 Feb 2008 11:04:10 -0800 >> From: Lloyd L Chambers >> To: James Gates >> CC: Dan Mick , lsarc-ext@Sun.COM >> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> <47BC97BB.8020607@sun.com >> > <47BCCD03.9060108@sun.com >> > <47BDAF65.1030802@sun.com> >> Sounds terrific! >> llc01 Are there any security issues with the memcached daemons, given >> that they're listening on ports? If I understand correctly, 10.0.0.x >> is a LAN address, which exposes the IP only to the local subnet. >> Still, can you say if there are concerns here? >> Lloyd Chambers >> LSARC >> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>> I've added the following summary to the details section of the >>> 1pager: >>> >>> memcached is a high-performance, distributed memory object >>> caching >>> system, generic in nature, but intended for use in speeding up >>> dynamic web applications by alleviating database load. >>> >>> Danga Interactive developed memcached to enhance the speed of >>> LiveJournal.com, a site which was already doing 20 million+ >>> dynamic page views per day for 1 million users with a bunch of >>> webservers and a bunch of database servers. memcached >>> dropped the >>> database load to almost nothing, yielding faster page load >>> times >>> for users, better resource utilization, and faster access >>> to the >>> databases on a memcache miss. >>> >>> How it Works >>> >>> First, you start up the memcached daemon on as many spare >>> machines >>> as you have. The daemon has no configuration file, just a few >>> command line options, only 3 or 4 of which you'll likely use: >>> >>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>> >>> This starts memcached up as a daemon, using 2GB of memory, and >>> listening on IP 10.0.0.40, port 11211. Because a 32-bit >>> process >>> can only address 4GB of virtual memory (usually significantly >>> less, depending on your operating system), if you have a 32- >>> bit >>> server with 4-64GB of memory using PAE you can just run >>> multiple >>> processes on the machine, each using 2 or 3GB of memory. >>> >>> Now, in your application, wherever you go to do a database >>> query, >>> first check the memcache. If the memcache returns an undefined >>> object, then go to the database, get what you're looking >>> for, and >>> put it in the memcache. >>> >>> >>> Dan Mick wrote: >>>> David.Comay@Sun.COM wrote: >>>>>> I have asked Roy to provide a one paragraph summary that I can >>>>>> add to >>>>>> the 1pager. But in the meantime, you can read >>>>>> http://www.danga.com/memcached/ and http://en.wikipedia.org/wiki/Memcached >>>>> >>>>> >>>>> Also as this is a version update to a previous case, you can >>>>> find out >>>>> more about memcached by looking at the earlier case, LSARC/ >>>>> 2007/385. >>>>> In particular, >>>>> >>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>> >>>>> dsc >>>> yes, although one sentence in the current case is pretty low-cost. >> --- >> Lloyd L Chambers >> lloyd.chambers@sun.com >> Sun Microsystems, Inc --- Lloyd L Chambers lloyd.chambers@sun.com Sun Microsystems, Inc From Roy.Lyseng@sun.com Mon Feb 25 12:32:03 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PKW3m8024762 for ; Mon, 25 Feb 2008 12:32:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1PKW2EK010662 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Feb 2008 13:32:03 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT0060RADDV300@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 12:32:01 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00KC2ADCZBF0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 12:32:01 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1PKVx33013648 for ; Mon, 25 Feb 2008 20:31:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00E01A86ZO00@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 20:31:59 +0000 (GMT) Received: from [10.0.0.18] ([80.203.115.203]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00MPNADA0D60@fe-emea-10.sun.com>; Mon, 25 Feb 2008 20:31:59 +0000 (GMT) Date: Mon, 25 Feb 2008 21:29:18 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: Sender: Roy.Lyseng@sun.com To: Lloyd L Chambers Cc: James Gates , lsarc-ext@sun.com Message-id: <47C3251E.1080300@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 6401 Lloyd L Chambers wrote: > Roy, > > Thanks. Does memcached issue a warning in the log if it starts > listening on ports at risk? No. Do you know a way to identify ports that are at risk? I guess we would need to communicate with firewalls in order to do this. Roy > > Lloyd > > On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: > >> Hi Lloyd, >> >> it is indeed possible to configure memcached to listen to local >> addresses only. If the administrator decides to configure memcached to >> listen on a publicly available address, a security hole may be opened. >> >> There was a substantial discussion on Memcached and security during >> the first ARC case (LSARC/2007/385). >> >> These issues were raised during that case (followed by my responses): >> >> Terrence Miller wrote: >> > tm-1 Can the client and server be on the same machine. If so, >> > can that system be configured to not accept requests >> > from the network. >> >> The server may be configured to listen on a user-defined port. A >> firewall may be configured to block that port. >> >> You can also configure memcached to listen on a specific interface, in >> particular the localhost interface. >> > >> > tm-2 Can an attack on the server cause it to overload its host >> > machine. >> >> I think that will be very difficult. Processing overhead is very light, >> it is actually more probable that the attacker will saturate the >> network. Besides, the memcached server is usually part of a backend >> system, residing on the same level as a backend database server and >> having an application server or web server in front. >> >> An attacker may attempt to fill the cache with garbage objects that >> invalidate the "valid" objects. This may become a problem if the >> attacker gets network access to the memcached server. >> > >> > tm-3 Does your documentation state the requirement for protecting >> > any network connecting clients to server. >> >> We do not provide documentation in addition to that provided by the >> community. >> > >> > tm-4 How hard is it to write a firewall rule that blocks all >> > memcached traffic. >> >> The server is usually listening on a single TCP socket, so it should be >> easy to write a firewall rule that blocks the associated port. As an >> option, the memcached server may also listen on a UDP socket, but this >> can also easily be protected. >> > >> > tm-5 Will the firewall requirements change with new releases. >> >> Impossible to say. The community designs and implements changes to the >> product. >> >> We ended up adding information to release notes that warn >> administrators about potential security holes when listening on >> publicly available ports. >> >> Hope this answers your questions, >> Roy >> >> James Gates wrote: >>> -------- Original Message -------- >>> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >>> OpenSolaris >>> Date: Fri, 22 Feb 2008 11:04:10 -0800 >>> From: Lloyd L Chambers >>> To: James Gates >>> CC: Dan Mick , lsarc-ext@Sun.COM >>> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> >>> <47BC97BB.8020607@sun.com> >>> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> >>> Sounds terrific! >>> llc01 Are there any security issues with the memcached daemons, given >>> that they're listening on ports? If I understand correctly, 10.0.0.x >>> is a LAN address, which exposes the IP only to the local subnet. >>> Still, can you say if there are concerns here? >>> Lloyd Chambers >>> LSARC >>> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>>> I've added the following summary to the details section of the 1pager: >>>> >>>> memcached is a high-performance, distributed memory object >>>> caching >>>> system, generic in nature, but intended for use in speeding up >>>> dynamic web applications by alleviating database load. >>>> >>>> Danga Interactive developed memcached to enhance the speed of >>>> LiveJournal.com, a site which was already doing 20 million+ >>>> dynamic page views per day for 1 million users with a bunch of >>>> webservers and a bunch of database servers. memcached dropped >>>> the >>>> database load to almost nothing, yielding faster page load times >>>> for users, better resource utilization, and faster access to the >>>> databases on a memcache miss. >>>> >>>> How it Works >>>> >>>> First, you start up the memcached daemon on as many spare >>>> machines >>>> as you have. The daemon has no configuration file, just a few >>>> command line options, only 3 or 4 of which you'll likely use: >>>> >>>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>>> >>>> This starts memcached up as a daemon, using 2GB of memory, and >>>> listening on IP 10.0.0.40, port 11211. Because a 32-bit process >>>> can only address 4GB of virtual memory (usually significantly >>>> less, depending on your operating system), if you have a 32-bit >>>> server with 4-64GB of memory using PAE you can just run multiple >>>> processes on the machine, each using 2 or 3GB of memory. >>>> >>>> Now, in your application, wherever you go to do a database >>>> query, >>>> first check the memcache. If the memcache returns an undefined >>>> object, then go to the database, get what you're looking for, >>>> and >>>> put it in the memcache. >>>> >>>> >>>> Dan Mick wrote: >>>>> David.Comay@Sun.COM wrote: >>>>>>> I have asked Roy to provide a one paragraph summary that I can >>>>>>> add to >>>>>>> the 1pager. But in the meantime, you can read >>>>>>> http://www.danga.com/memcached/ and >>>>>>> http://en.wikipedia.org/wiki/Memcached >>>>>> >>>>>> >>>>>> Also as this is a version update to a previous case, you can find >>>>>> out >>>>>> more about memcached by looking at the earlier case, LSARC/2007/385. >>>>>> In particular, >>>>>> >>>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>>> >>>>>> dsc >>>>> yes, although one sentence in the current case is pretty low-cost. >>> --- >>> Lloyd L Chambers >>> lloyd.chambers@sun.com >>> Sun Microsystems, Inc > > --- > Lloyd L Chambers > lloyd.chambers@sun.com > Sun Microsystems, Inc > > > From danek.duvall@sun.com Mon Feb 25 13:15:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PLF1oa026645 for ; Mon, 25 Feb 2008 13:15:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1PLF0lx025993 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Feb 2008 13:15:01 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00807CD0NN00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 13:15:00 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT003XJCCXBP90@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 13:14:57 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1PLEuPS040998; Mon, 25 Feb 2008 13:14:56 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1PLEtCJ017684; Mon, 25 Feb 2008 13:14:55 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1PLEtbH017683; Mon, 25 Feb 2008 13:14:55 -0800 (PST) Date: Mon, 25 Feb 2008 13:14:55 -0800 From: Danek Duvall Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47BC5F15.3050205@sun.com> To: James Gates Cc: lsarc-ext@sun.com Message-id: <20080225211455.GK9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1254 On Wed, Feb 20, 2008 at 12:10:45PM -0500, James Gates wrote: > 4. Technical Description: > 4.1 Details > The update to the memcached daemon is mostly a version upgrade. > An additional option is made to enhance large memory utilization. > > The Java API was described in LSARC/2007/385, but was not included > at that time due to missing OSR approval (time constrained). You don't list the Java API in the interface table. What's the commitment level? > The libmemcached C API includes a set of binary utility programs. > These are all placed in the /usr/memcached/bin directory and are given > a Volatile stability classification. > They are only meant for ad-hoc use. > Their man pages are placed in /usr/memcached/share/man. Hrm. I'm really not a big fan of creating new entries under /usr just for a handful of utilities. At the very least, the man pages should just go in /usr/share/man (otherwise they're not discoverable). Probably the utilities should go in /usr/bin. The names are somewhat generic, but not hugely so. > Dtrace probes are described in attached memcached_dtrace.d. Have you run the probes past the dtrace community? Danek From james.gates@sun.com Mon Feb 25 13:56:10 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PLu94j027800 for ; Mon, 25 Feb 2008 13:56:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1PLu6UX005485 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Feb 2008 21:56:08 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00A0LE9JFA00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 13:56:07 -0800 (PST) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT003ZHE9HBPE0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Feb 2008 13:56:06 -0800 (PST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1PLu1j8020438; Mon, 25 Feb 2008 21:56:01 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-66-20.East.Sun.COM [129.150.66.20]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m1PLtfr3025296; Mon, 25 Feb 2008 21:55:52 +0000 (GMT) Date: Mon, 25 Feb 2008 16:55:05 -0500 From: James Gates Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <20080225211455.GK9130@zruty.sfbay.sun.com> To: Danek Duvall , lsarc-ext@sun.com Message-id: <47C33939.8010305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <20080225211455.GK9130@zruty.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 1736 I'll ask Roy about the Java API & if the probes have been discussed with the community. As for putting the commands in /usr/memcached/bin, we thought that names like 'memcat', 'memstat', 'memerror', etc. *are* too generic, and were preempting complaints about such commands in /usr/bin. I think the project team would be happy to locate them in /usr/bin. Does anyone in LSARC have a view on the issue? Danek Duvall wrote: > On Wed, Feb 20, 2008 at 12:10:45PM -0500, James Gates wrote: > > >>4. Technical Description: >> 4.1 Details >> The update to the memcached daemon is mostly a version upgrade. >> An additional option is made to enhance large memory utilization. >> >> The Java API was described in LSARC/2007/385, but was not included >> at that time due to missing OSR approval (time constrained). > > > You don't list the Java API in the interface table. What's the commitment > level? > > >> The libmemcached C API includes a set of binary utility programs. >> These are all placed in the /usr/memcached/bin directory and are given >> a Volatile stability classification. >> They are only meant for ad-hoc use. >> Their man pages are placed in /usr/memcached/share/man. > > > Hrm. I'm really not a big fan of creating new entries under /usr just for > a handful of utilities. At the very least, the man pages should just go in > /usr/share/man (otherwise they're not discoverable). Probably the > utilities should go in /usr/bin. The names are somewhat generic, but not > hugely so. > > >> Dtrace probes are described in attached memcached_dtrace.d. > > > Have you run the probes past the dtrace community? > > Danek From jyri@buye.red.iplanet.com Mon Feb 25 18:46:20 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q2kKOQ008868 for ; Mon, 25 Feb 2008 18:46:20 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q2k4rS032279; Mon, 25 Feb 2008 19:46:06 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00G1JROTKS00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 18:46:05 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00JJLRO1YSC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 18:45:37 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1Q2jbS3009357; Mon, 25 Feb 2008 18:45:37 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1Q2jb52009356; Mon, 25 Feb 2008 18:45:37 -0800 (PST) Date: Mon, 25 Feb 2008 18:45:37 -0800 From: Jyri Virkki Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C3251E.1080300@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com Message-id: <20080226024537.GP7744@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 383 Roy Lyseng wrote: > > >Thanks. Does memcached issue a warning in the log if it starts > >listening on ports at risk? > > No. Do you know a way to identify ports that are at risk? I guess we > would need to communicate with firewalls in order to do this. Does it listen on all interfaces by default or only locahost? -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Roy.Lyseng@sun.com Tue Feb 26 00:11:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q8BpM7018013 for ; Tue, 26 Feb 2008 00:11:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q8Bnkt015946 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 08:11:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU0070L6RP8V00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 01:11:49 -0700 (MST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU005TU6ROVTB0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 01:11:49 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q8Bmrq028141 for ; Tue, 26 Feb 2008 08:11:48 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU008016QXJC00@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 08:11:48 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU0005C6RNFAG0@fe-emea-09.sun.com>; Tue, 26 Feb 2008 08:11:48 +0000 (GMT) Date: Tue, 26 Feb 2008 09:09:07 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <20080226024537.GP7744@sun.com> Sender: Roy.Lyseng@sun.com To: Jyri Virkki Cc: James Gates , lsarc-ext@sun.com Message-id: <47C3C923.3060402@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <20080226024537.GP7744@sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 470 Jyri Virkki wrote: > Roy Lyseng wrote: >>> Thanks. Does memcached issue a warning in the log if it starts >>> listening on ports at risk? >> No. Do you know a way to identify ports that are at risk? I guess we >> would need to communicate with firewalls in order to do this. > > Does it listen on all interfaces by default or only locahost? The default is to bind with INADDR_ANY. You can set it to listen to a single specific interface with the -l option. Roy From casper@holland.sun.com Tue Feb 26 00:54:10 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q8sAUS019453 for ; Tue, 26 Feb 2008 00:54:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q8s9GY027891 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Tue, 26 Feb 2008 00:54:09 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00L0R8Q83D00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 00:54:08 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU0090Z8Q6I7B0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 00:54:07 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m1Q8s4KG022132; Tue, 26 Feb 2008 08:54:04 +0000 (GMT) Date: Tue, 26 Feb 2008 09:54:04 +0100 From: Casper.Dik@sun.com Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C3C923.3060402@sun.com> Sender: casper@holland.sun.com To: Roy Lyseng Cc: Jyri Virkki , James Gates , lsarc-ext@sun.com Message-id: <200802260854.m1Q8s4KG022132@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <20080226024537.GP7744@sun.com> <47C3C923.3060402@sun.com> Status: RO Content-Length: 618 > > >Jyri Virkki wrote: >> Roy Lyseng wrote: >>>> Thanks. Does memcached issue a warning in the log if it starts >>>> listening on ports at risk? >>> No. Do you know a way to identify ports that are at risk? I guess we >>> would need to communicate with firewalls in order to do this. >> >> Does it listen on all interfaces by default or only locahost? > >The default is to bind with INADDR_ANY. You can set it to listen to a >single specific interface with the -l option. Is there any reason for memcached to expect calls from remote systems? If not, then it should not answer them/listen for them. Casper From Roy.Lyseng@sun.com Tue Feb 26 06:12:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QECTLX027661 for ; Tue, 26 Feb 2008 06:12:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QECTbH014599 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 06:12:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00B01NGSRN00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 06:12:28 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00B6HNGQ2010@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 06:12:27 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QECQMX007964 for ; Tue, 26 Feb 2008 14:12:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00801NB55700@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 14:12:26 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU002XXNGMH920@fe-emea-10.sun.com>; Tue, 26 Feb 2008 14:12:22 +0000 (GMT) Date: Tue, 26 Feb 2008 15:09:40 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <200802260854.m1Q8s4KG022132@dm-holland-02.uk.sun.com> Sender: Roy.Lyseng@sun.com To: Casper.Dik@sun.com Cc: Jyri Virkki , James Gates , lsarc-ext@sun.com Message-id: <47C41DA4.6040601@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <20080226024537.GP7744@sun.com> <47C3C923.3060402@sun.com> <200802260854.m1Q8s4KG022132@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 2024 Casper.Dik@Sun.COM wrote: >> >> Jyri Virkki wrote: >>> Roy Lyseng wrote: >>>>> Thanks. Does memcached issue a warning in the log if it starts >>>>> listening on ports at risk? >>>> No. Do you know a way to identify ports that are at risk? I guess we >>>> would need to communicate with firewalls in order to do this. >>> Does it listen on all interfaces by default or only locahost? >> The default is to bind with INADDR_ANY. You can set it to listen to a >> single specific interface with the -l option. > > > Is there any reason for memcached to expect calls from remote systems? > > If not, then it should not answer them/listen for them. memcached is a very specialized component, usually being used in a Webstack setup as an offload engine for database accesses. It is also mostly used in larger setups where we have multiple web servers. If a single web server would suffice, then a non-distributed cache manager would be faster than memcached. Thus, the typical setup would be like this: ------------------------------ | web server tier (10-10000) | ------------------------------ I I I I I I --------------------------- --------------------------- | database tier (2-1000) | | memcached tier (2-1000) | --------------------------- --------------------------- Numbers in parentheses indicate number of machines. Database tier and memcached tier are presented at same level (they do not know about each other). When a data object is looked up by a web server machine, it will first ask the proper machine in the memcached tier. If found, request is complete. If not found, database is consulted, and object is inserted into memcached tier. For all practical purposes, we would assume that administrators know what they are doing and will only assign local addresses to the memcached machines. Memcached functions *may* be co-located with other functions (e.g. web server tier) but this is highly unusual. Roy > > Casper > From Roy.Lyseng@sun.com Tue Feb 26 06:14:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QEEFe1027999 for ; Tue, 26 Feb 2008 06:14:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1QEEDxq013138 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 22:14:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00105NJOO200@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 06:14:12 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU001WPNJNAF10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 06:14:12 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QEEAFg008196 for ; Tue, 26 Feb 2008 14:14:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00801NB55700@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 14:14:10 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU002OMNJAH930@fe-emea-10.sun.com>; Tue, 26 Feb 2008 14:13:58 +0000 (GMT) Date: Tue, 26 Feb 2008 15:11:17 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C33A0B.4040902@sun.com> Sender: Roy.Lyseng@sun.com To: James Gates , lsarc-ext@sun.com Message-id: <47C41E05.1080006@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 2840 James Gates wrote: > Can you answer the questions about the Java API & if the probes have > been discussed with the community. Thanks. > > > -------- Original Message -------- > Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris > Date: Mon, 25 Feb 2008 16:55:05 -0500 > From: James Gates > To: Danek Duvall , lsarc-ext@sun.com > References: <47BC5F15.3050205@sun.com> > <20080225211455.GK9130@zruty.sfbay.sun.com> > > I'll ask Roy about the Java API & if the probes have been discussed with > the community. Java API: The commitment level for the Java API was classified as Volatile in LSARC/2007/385. Based on recent discussions, I am open for reclassifying this as Uncommitted, if this is the ARCs opinion. Dtrace probes: My apologies for not having discussed this. A separate mail is being sent to dtrace-discuss@opensolaris.org ASAP. > > As for putting the commands in /usr/memcached/bin, we thought that names > like 'memcat', 'memstat', 'memerror', etc. *are* too generic, and were > preempting complaints about such commands in /usr/bin. > > I think the project team would be happy to locate them in /usr/bin. I have a concern with the utility names too (I would really see them merged into a single utility with subcommands), but of course it is simpler for us to put everything into /usr/bin... Roy > > Does anyone in LSARC have a view on the issue? > > > Danek Duvall wrote: >> On Wed, Feb 20, 2008 at 12:10:45PM -0500, James Gates wrote: >> >> >>> 4. Technical Description: >>> 4.1 Details >>> The update to the memcached daemon is mostly a version upgrade. >>> An additional option is made to enhance large memory >>> utilization. >>> >>> The Java API was described in LSARC/2007/385, but was not >>> included >>> at that time due to missing OSR approval (time constrained). >> >> >> You don't list the Java API in the interface table. What's the >> commitment >> level? >> >> >>> The libmemcached C API includes a set of binary utility >>> programs. >>> These are all placed in the /usr/memcached/bin directory and >>> are given >>> a Volatile stability classification. >>> They are only meant for ad-hoc use. >>> Their man pages are placed in /usr/memcached/share/man. >> >> >> Hrm. I'm really not a big fan of creating new entries under /usr just >> for >> a handful of utilities. At the very least, the man pages should just >> go in >> /usr/share/man (otherwise they're not discoverable). Probably the >> utilities should go in /usr/bin. The names are somewhat generic, but not >> hugely so. >> >> >>> Dtrace probes are described in attached memcached_dtrace.d. >> >> >> Have you run the probes past the dtrace community? >> >> Danek > From Lloyd.Chambers@sun.com Tue Feb 26 09:51:06 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QHp6qM005869 for ; Tue, 26 Feb 2008 09:51:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QHp5C0029254 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 09:51:05 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00J17XL3R600@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:51:03 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00G81XKZRS50@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:50:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QHowA4003107 for ; Tue, 26 Feb 2008 09:50:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00901USBL200@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:50:58 -0800 (PST) Received: from [192.168.1.8] ([129.150.19.232]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU00NUYXKW3H00@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 09:50:56 -0800 (PST) Date: Tue, 26 Feb 2008 09:50:55 -0800 From: Lloyd L Chambers Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: <47C33939.8010305@sun.com> Sender: Lloyd.Chambers@sun.com To: James Gates Cc: Danek Duvall , lsarc-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <20080225211455.GK9130@zruty.sfbay.sun.com> <47C33939.8010305@sun.com> Status: RO Content-Length: 2054 Wouldn't /usr/bin/memcached make more sense then /usr/memcached/bin? I think a namespace like memc_cat, memc_stat, memc_error would be good. Lloyd On Feb 25, 2008, at 1:55 PM, James Gates wrote: > I'll ask Roy about the Java API & if the probes have been discussed > with the community. > > As for putting the commands in /usr/memcached/bin, we thought that > names like 'memcat', 'memstat', 'memerror', etc. *are* too generic, > and were preempting complaints about such commands in /usr/bin. > > I think the project team would be happy to locate them in /usr/bin. > > Does anyone in LSARC have a view on the issue? > > > Danek Duvall wrote: >> On Wed, Feb 20, 2008 at 12:10:45PM -0500, James Gates wrote: >>> 4. Technical Description: >>> 4.1 Details >>> The update to the memcached daemon is mostly a version >>> upgrade. >>> An additional option is made to enhance large memory >>> utilization. >>> >>> The Java API was described in LSARC/2007/385, but was not >>> included >>> at that time due to missing OSR approval (time constrained). >> You don't list the Java API in the interface table. What's the >> commitment >> level? >>> The libmemcached C API includes a set of binary utility >>> programs. >>> These are all placed in the /usr/memcached/bin directory >>> and are given >>> a Volatile stability classification. >>> They are only meant for ad-hoc use. >>> Their man pages are placed in /usr/memcached/share/man. >> Hrm. I'm really not a big fan of creating new entries under /usr >> just for >> a handful of utilities. At the very least, the man pages should >> just go in >> /usr/share/man (otherwise they're not discoverable). Probably the >> utilities should go in /usr/bin. The names are somewhat generic, >> but not >> hugely so. >>> Dtrace probes are described in attached memcached_dtrace.d. >> Have you run the probes past the dtrace community? >> Danek --- Lloyd L Chambers lloyd.chambers@sun.com Sun Microsystems, Inc From Lloyd.Chambers@sun.com Tue Feb 26 09:52:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QHqxSv005995 for ; Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QHqxMi021137 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00L0NXOBP100@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00HU7XOBYIE0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QHqxs7003361 for ; Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00101X82KT00@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 09:52:59 -0800 (PST) Received: from [192.168.1.8] ([129.150.19.232]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU00NVEXO53H00@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 09:52:58 -0800 (PST) Date: Tue, 26 Feb 2008 09:52:53 -0800 From: Lloyd L Chambers Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C3251E.1080300@sun.com> Sender: Lloyd.Chambers@sun.com To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com Message-id: <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> Status: RO Content-Length: 7028 No, I'm just suggesting that ANY non-loopback port is a risk, and issuing a warning would be worthwhile: NOTE: port dddd is a non-local port. Be sure your firewall setup blocks inappropriate access to this port. On Feb 25, 2008, at 12:29 PM, Roy Lyseng wrote: > > > Lloyd L Chambers wrote: >> Roy, >> Thanks. Does memcached issue a warning in the log if it starts >> listening on ports at risk? > > No. Do you know a way to identify ports that are at risk? I guess we > would need to communicate with firewalls in order to do this. > > Roy >> Lloyd >> On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: >>> Hi Lloyd, >>> >>> it is indeed possible to configure memcached to listen to local >>> addresses only. If the administrator decides to configure >>> memcached to listen on a publicly available address, a security >>> hole may be opened. >>> >>> There was a substantial discussion on Memcached and security >>> during the first ARC case (LSARC/2007/385). >>> >>> These issues were raised during that case (followed by my >>> responses): >>> >>> Terrence Miller wrote: >>> > tm-1 Can the client and server be on the same machine. If so, >>> > can that system be configured to not accept requests >>> > from the network. >>> >>> The server may be configured to listen on a user-defined port. A >>> firewall may be configured to block that port. >>> >>> You can also configure memcached to listen on a specific >>> interface, in >>> particular the localhost interface. >>> > >>> > tm-2 Can an attack on the server cause it to overload its host >>> > machine. >>> >>> I think that will be very difficult. Processing overhead is very >>> light, >>> it is actually more probable that the attacker will saturate the >>> network. Besides, the memcached server is usually part of a backend >>> system, residing on the same level as a backend database server and >>> having an application server or web server in front. >>> >>> An attacker may attempt to fill the cache with garbage objects that >>> invalidate the "valid" objects. This may become a problem if the >>> attacker gets network access to the memcached server. >>> > >>> > tm-3 Does your documentation state the requirement for >>> protecting >>> > any network connecting clients to server. >>> >>> We do not provide documentation in addition to that provided by the >>> community. >>> > >>> > tm-4 How hard is it to write a firewall rule that blocks all >>> > memcached traffic. >>> >>> The server is usually listening on a single TCP socket, so it >>> should be >>> easy to write a firewall rule that blocks the associated port. As an >>> option, the memcached server may also listen on a UDP socket, but >>> this >>> can also easily be protected. >>> > >>> > tm-5 Will the firewall requirements change with new releases. >>> >>> Impossible to say. The community designs and implements changes to >>> the >>> product. >>> >>> We ended up adding information to release notes that warn >>> administrators about potential security holes when listening on >>> publicly available ports. >>> >>> Hope this answers your questions, >>> Roy >>> >>> James Gates wrote: >>>> -------- Original Message -------- >>>> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >>>> OpenSolaris >>>> Date: Fri, 22 Feb 2008 11:04:10 -0800 >>>> From: Lloyd L Chambers >>>> To: James Gates >>>> CC: Dan Mick , lsarc-ext@Sun.COM >>>> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> >>>> <47BC97BB.8020607@sun.com> >>> 4.61.0802201416370.1507@izimbra> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com >>>> > >>>> Sounds terrific! >>>> llc01 Are there any security issues with the memcached daemons, >>>> given >>>> that they're listening on ports? If I understand correctly, >>>> 10.0.0.x >>>> is a LAN address, which exposes the IP only to the local subnet. >>>> Still, can you say if there are concerns here? >>>> Lloyd Chambers >>>> LSARC >>>> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>>>> I've added the following summary to the details section of the >>>>> 1pager: >>>>> >>>>> memcached is a high-performance, distributed memory object >>>>> caching >>>>> system, generic in nature, but intended for use in speeding >>>>> up >>>>> dynamic web applications by alleviating database load. >>>>> >>>>> Danga Interactive developed memcached to enhance the speed of >>>>> LiveJournal.com, a site which was already doing 20 million+ >>>>> dynamic page views per day for 1 million users with a bunch >>>>> of >>>>> webservers and a bunch of database servers. memcached >>>>> dropped the >>>>> database load to almost nothing, yielding faster page load >>>>> times >>>>> for users, better resource utilization, and faster access >>>>> to the >>>>> databases on a memcache miss. >>>>> >>>>> How it Works >>>>> >>>>> First, you start up the memcached daemon on as many spare >>>>> machines >>>>> as you have. The daemon has no configuration file, just a few >>>>> command line options, only 3 or 4 of which you'll likely use: >>>>> >>>>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>>>> >>>>> This starts memcached up as a daemon, using 2GB of memory, >>>>> and >>>>> listening on IP 10.0.0.40, port 11211. Because a 32-bit >>>>> process >>>>> can only address 4GB of virtual memory (usually significantly >>>>> less, depending on your operating system), if you have a 32- >>>>> bit >>>>> server with 4-64GB of memory using PAE you can just run >>>>> multiple >>>>> processes on the machine, each using 2 or 3GB of memory. >>>>> >>>>> Now, in your application, wherever you go to do a database >>>>> query, >>>>> first check the memcache. If the memcache returns an >>>>> undefined >>>>> object, then go to the database, get what you're looking >>>>> for, and >>>>> put it in the memcache. >>>>> >>>>> >>>>> Dan Mick wrote: >>>>>> David.Comay@Sun.COM wrote: >>>>>>>> I have asked Roy to provide a one paragraph summary that I >>>>>>>> can add to >>>>>>>> the 1pager. But in the meantime, you can read >>>>>>>> http://www.danga.com/memcached/ and http://en.wikipedia.org/wiki/Memcached >>>>>>> >>>>>>> >>>>>>> Also as this is a version update to a previous case, you can >>>>>>> find out >>>>>>> more about memcached by looking at the earlier case, LSARC/ >>>>>>> 2007/385. >>>>>>> In particular, >>>>>>> >>>>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>>>> >>>>>>> dsc >>>>>> yes, although one sentence in the current case is pretty low- >>>>>> cost. >>>> --- >>>> Lloyd L Chambers >>>> lloyd.chambers@sun.com >>>> Sun Microsystems, Inc >> --- >> Lloyd L Chambers >> lloyd.chambers@sun.com >> Sun Microsystems, Inc --- Lloyd L Chambers lloyd.chambers@sun.com Sun Microsystems, Inc From Roy.Lyseng@sun.com Tue Feb 26 10:02:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QI2PgU006753 for ; Tue, 26 Feb 2008 10:02:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1QI2NUo013213 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Feb 2008 02:02:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00M01Y3ZHU00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 10:02:23 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00LAQY3WRO00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 10:02:21 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QI2KFT018922 for ; Tue, 26 Feb 2008 18:02:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00B01XV6JV00@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 18:02:20 +0000 (GMT) Received: from [10.0.0.18] ([80.203.115.203]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU009KGY3VPC20@fe-emea-09.sun.com>; Tue, 26 Feb 2008 18:02:20 +0000 (GMT) Date: Tue, 26 Feb 2008 18:59:38 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> Sender: Roy.Lyseng@sun.com To: Lloyd L Chambers Cc: James Gates , lsarc-ext@sun.com Message-id: <47C4538A.80707@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 7410 Lloyd L Chambers wrote: > No, I'm just suggesting that ANY non-loopback port is a risk, and > issuing a warning would be worthwhile: > > NOTE: port dddd is a non-local port. Be sure your firewall setup > blocks inappropriate access to this port. Not sure if I appreciate this. Setting up memcached to listen on a loopback interface does not make sense, as it is always used in machine-to-machine communication. Is there any other product that actually do this? BTW, I guess you really mean interface, and not port? Thanks, Roy > > On Feb 25, 2008, at 12:29 PM, Roy Lyseng wrote: > >> >> >> Lloyd L Chambers wrote: >>> Roy, >>> Thanks. Does memcached issue a warning in the log if it starts >>> listening on ports at risk? >> >> No. Do you know a way to identify ports that are at risk? I guess we >> would need to communicate with firewalls in order to do this. >> >> Roy >>> Lloyd >>> On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: >>>> Hi Lloyd, >>>> >>>> it is indeed possible to configure memcached to listen to local >>>> addresses only. If the administrator decides to configure memcached >>>> to listen on a publicly available address, a security hole may be >>>> opened. >>>> >>>> There was a substantial discussion on Memcached and security during >>>> the first ARC case (LSARC/2007/385). >>>> >>>> These issues were raised during that case (followed by my responses): >>>> >>>> Terrence Miller wrote: >>>> > tm-1 Can the client and server be on the same machine. If so, >>>> > can that system be configured to not accept requests >>>> > from the network. >>>> >>>> The server may be configured to listen on a user-defined port. A >>>> firewall may be configured to block that port. >>>> >>>> You can also configure memcached to listen on a specific interface, in >>>> particular the localhost interface. >>>> > >>>> > tm-2 Can an attack on the server cause it to overload its host >>>> > machine. >>>> >>>> I think that will be very difficult. Processing overhead is very light, >>>> it is actually more probable that the attacker will saturate the >>>> network. Besides, the memcached server is usually part of a backend >>>> system, residing on the same level as a backend database server and >>>> having an application server or web server in front. >>>> >>>> An attacker may attempt to fill the cache with garbage objects that >>>> invalidate the "valid" objects. This may become a problem if the >>>> attacker gets network access to the memcached server. >>>> > >>>> > tm-3 Does your documentation state the requirement for protecting >>>> > any network connecting clients to server. >>>> >>>> We do not provide documentation in addition to that provided by the >>>> community. >>>> > >>>> > tm-4 How hard is it to write a firewall rule that blocks all >>>> > memcached traffic. >>>> >>>> The server is usually listening on a single TCP socket, so it should be >>>> easy to write a firewall rule that blocks the associated port. As an >>>> option, the memcached server may also listen on a UDP socket, but this >>>> can also easily be protected. >>>> > >>>> > tm-5 Will the firewall requirements change with new releases. >>>> >>>> Impossible to say. The community designs and implements changes to the >>>> product. >>>> >>>> We ended up adding information to release notes that warn >>>> administrators about potential security holes when listening on >>>> publicly available ports. >>>> >>>> Hope this answers your questions, >>>> Roy >>>> >>>> James Gates wrote: >>>>> -------- Original Message -------- >>>>> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >>>>> OpenSolaris >>>>> Date: Fri, 22 Feb 2008 11:04:10 -0800 >>>>> From: Lloyd L Chambers >>>>> To: James Gates >>>>> CC: Dan Mick , lsarc-ext@Sun.COM >>>>> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> >>>>> <47BC97BB.8020607@sun.com> >>>>> >>>>> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> >>>>> Sounds terrific! >>>>> llc01 Are there any security issues with the memcached daemons, given >>>>> that they're listening on ports? If I understand correctly, 10.0.0.x >>>>> is a LAN address, which exposes the IP only to the local subnet. >>>>> Still, can you say if there are concerns here? >>>>> Lloyd Chambers >>>>> LSARC >>>>> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>>>>> I've added the following summary to the details section of the >>>>>> 1pager: >>>>>> >>>>>> memcached is a high-performance, distributed memory object >>>>>> caching >>>>>> system, generic in nature, but intended for use in speeding up >>>>>> dynamic web applications by alleviating database load. >>>>>> >>>>>> Danga Interactive developed memcached to enhance the speed of >>>>>> LiveJournal.com, a site which was already doing 20 million+ >>>>>> dynamic page views per day for 1 million users with a bunch of >>>>>> webservers and a bunch of database servers. memcached >>>>>> dropped the >>>>>> database load to almost nothing, yielding faster page load >>>>>> times >>>>>> for users, better resource utilization, and faster access to >>>>>> the >>>>>> databases on a memcache miss. >>>>>> >>>>>> How it Works >>>>>> >>>>>> First, you start up the memcached daemon on as many spare >>>>>> machines >>>>>> as you have. The daemon has no configuration file, just a few >>>>>> command line options, only 3 or 4 of which you'll likely use: >>>>>> >>>>>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>>>>> >>>>>> This starts memcached up as a daemon, using 2GB of memory, and >>>>>> listening on IP 10.0.0.40, port 11211. Because a 32-bit process >>>>>> can only address 4GB of virtual memory (usually significantly >>>>>> less, depending on your operating system), if you have a 32-bit >>>>>> server with 4-64GB of memory using PAE you can just run >>>>>> multiple >>>>>> processes on the machine, each using 2 or 3GB of memory. >>>>>> >>>>>> Now, in your application, wherever you go to do a database >>>>>> query, >>>>>> first check the memcache. If the memcache returns an undefined >>>>>> object, then go to the database, get what you're looking >>>>>> for, and >>>>>> put it in the memcache. >>>>>> >>>>>> >>>>>> Dan Mick wrote: >>>>>>> David.Comay@Sun.COM wrote: >>>>>>>>> I have asked Roy to provide a one paragraph summary that I can >>>>>>>>> add to >>>>>>>>> the 1pager. But in the meantime, you can read >>>>>>>>> http://www.danga.com/memcached/ and >>>>>>>>> http://en.wikipedia.org/wiki/Memcached >>>>>>>> >>>>>>>> >>>>>>>> Also as this is a version update to a previous case, you can >>>>>>>> find out >>>>>>>> more about memcached by looking at the earlier case, >>>>>>>> LSARC/2007/385. >>>>>>>> In particular, >>>>>>>> >>>>>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>>>>> >>>>>>>> dsc >>>>>>> yes, although one sentence in the current case is pretty low-cost. >>>>> --- >>>>> Lloyd L Chambers >>>>> lloyd.chambers@sun.com >>>>> Sun Microsystems, Inc >>> --- >>> Lloyd L Chambers >>> lloyd.chambers@sun.com >>> Sun Microsystems, Inc > > --- > Lloyd L Chambers > lloyd.chambers@sun.com > Sun Microsystems, Inc > > > From danek.duvall@sun.com Tue Feb 26 10:03:53 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QI3rfa006833 for ; Tue, 26 Feb 2008 10:03:53 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QI3pso003042 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Tue, 26 Feb 2008 10:03:53 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU0060HY6GNP00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 11:03:52 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU0047CY6FUV30@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 11:03:51 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1QI3mRJ061810; Tue, 26 Feb 2008 10:03:48 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QI3mLu024948; Tue, 26 Feb 2008 10:03:48 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1QI3md8024947; Tue, 26 Feb 2008 10:03:48 -0800 (PST) Date: Tue, 26 Feb 2008 10:03:47 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C41E05.1080006@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com Message-id: <20080226180347.GX9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1932 On Tue, Feb 26, 2008 at 03:11:17PM +0100, Roy Lyseng wrote: > Java API: The commitment level for the Java API was classified as > Volatile in LSARC/2007/385. Based on recent discussions, I am open for > reclassifying this as Uncommitted, if this is the ARCs opinion. Ah, okay. If you're comfortable that the interfaces are sufficiently stable to be considered Uncommitted, then that's fine, and the ARC would generally prefer that building blocks like APIs be Uncommitted or better, but committing too strongly to an interface is problematic, too. > Dtrace probes: My apologies for not having discussed this. A separate > mail is being sent to dtrace-discuss@opensolaris.org ASAP. Thanks. > > As for putting the commands in /usr/memcached/bin, we thought that > > names like 'memcat', 'memstat', 'memerror', etc. *are* too generic, and > > were preempting complaints about such commands in /usr/bin. > > > > I think the project team would be happy to locate them in /usr/bin. > > I have a concern with the utility names too (I would really see them > merged into a single utility with subcommands), but of course it is > simpler for us to put everything into /usr/bin... Yeah, I was thinking that they'd make for good subcommands, too. What does memcached do in its default installation? What do Linux distros do with these utilities? I would suggest that you ping the memcached community and see if they'd be willing to accept a change modifying these commands to be subcommands of a wrapper. But if they've been around a long time and reasonably consistently delivered in /usr/bin as-is, then they might not be terribly open to that. If they *were* willing to accept such a change, then you could integrate them as-is in /usr/bin now (as Volatile or Obsolete), and change them later, when you get the changes integrated in mainline memcached. I'm not going to push you too hard in that direction, though. Danek From james.gates@sun.com Tue Feb 26 10:33:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QIXrSu009161 for ; Tue, 26 Feb 2008 10:33:54 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1QIXpmE025949 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Feb 2008 02:33:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00203ZKF8M00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 10:33:51 -0800 (PST) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00L7DZKERI30@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Feb 2008 10:33:50 -0800 (PST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QIXmVx012787; Tue, 26 Feb 2008 18:33:48 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-66-13.East.Sun.COM [129.150.66.13]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m1QIXN2c011262; Tue, 26 Feb 2008 18:33:31 +0000 (GMT) Date: Tue, 26 Feb 2008 13:32:50 -0500 From: James Gates Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C4538A.80707@sun.com> To: Roy Lyseng Cc: Lloyd L Chambers , lsarc-ext@sun.com Message-id: <47C45B52.7070600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 8449 This case has just been discussed in the weekly LSARC meeting. Listening on INADDR_ANY was accepted on the basis that in typical (if not all) deployments, multiple memcached deamons cooperate in a distributed environment to provide a very large virtual cache (i.e. utilizing the memory of many systems). Even if we made it listen only on loopback interfaces by default, users would immediately change that upon installation. The timer for this case was extended by a week though (it now times out on 6th March). This is to conclude the discussion for 2 outstanding issues: 1) Command names in /usr/bin, and community acceptance of a change to the names (or a wrapper) 2) Acceptance of the Drtace probes Roy Lyseng wrote: > > > Lloyd L Chambers wrote: > >> No, I'm just suggesting that ANY non-loopback port is a risk, and >> issuing a warning would be worthwhile: >> >> NOTE: port dddd is a non-local port. Be sure your firewall setup >> blocks inappropriate access to this port. > > > Not sure if I appreciate this. Setting up memcached to listen on a > loopback interface does not make sense, as it is always used in > machine-to-machine communication. Is there any other product that > actually do this? > > BTW, I guess you really mean interface, and not port? > > Thanks, > Roy > >> >> On Feb 25, 2008, at 12:29 PM, Roy Lyseng wrote: >> >>> >>> >>> Lloyd L Chambers wrote: >>> >>>> Roy, >>>> Thanks. Does memcached issue a warning in the log if it starts >>>> listening on ports at risk? >>> >>> >>> No. Do you know a way to identify ports that are at risk? I guess we >>> would need to communicate with firewalls in order to do this. >>> >>> Roy >>> >>>> Lloyd >>>> On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: >>>> >>>>> Hi Lloyd, >>>>> >>>>> it is indeed possible to configure memcached to listen to local >>>>> addresses only. If the administrator decides to configure memcached >>>>> to listen on a publicly available address, a security hole may be >>>>> opened. >>>>> >>>>> There was a substantial discussion on Memcached and security during >>>>> the first ARC case (LSARC/2007/385). >>>>> >>>>> These issues were raised during that case (followed by my responses): >>>>> >>>>> Terrence Miller wrote: >>>>> > tm-1 Can the client and server be on the same machine. If so, >>>>> > can that system be configured to not accept requests >>>>> > from the network. >>>>> >>>>> The server may be configured to listen on a user-defined port. A >>>>> firewall may be configured to block that port. >>>>> >>>>> You can also configure memcached to listen on a specific interface, in >>>>> particular the localhost interface. >>>>> > >>>>> > tm-2 Can an attack on the server cause it to overload its host >>>>> > machine. >>>>> >>>>> I think that will be very difficult. Processing overhead is very >>>>> light, >>>>> it is actually more probable that the attacker will saturate the >>>>> network. Besides, the memcached server is usually part of a backend >>>>> system, residing on the same level as a backend database server and >>>>> having an application server or web server in front. >>>>> >>>>> An attacker may attempt to fill the cache with garbage objects that >>>>> invalidate the "valid" objects. This may become a problem if the >>>>> attacker gets network access to the memcached server. >>>>> > >>>>> > tm-3 Does your documentation state the requirement for protecting >>>>> > any network connecting clients to server. >>>>> >>>>> We do not provide documentation in addition to that provided by the >>>>> community. >>>>> > >>>>> > tm-4 How hard is it to write a firewall rule that blocks all >>>>> > memcached traffic. >>>>> >>>>> The server is usually listening on a single TCP socket, so it >>>>> should be >>>>> easy to write a firewall rule that blocks the associated port. As an >>>>> option, the memcached server may also listen on a UDP socket, but this >>>>> can also easily be protected. >>>>> > >>>>> > tm-5 Will the firewall requirements change with new releases. >>>>> >>>>> Impossible to say. The community designs and implements changes to the >>>>> product. >>>>> >>>>> We ended up adding information to release notes that warn >>>>> administrators about potential security holes when listening on >>>>> publicly available ports. >>>>> >>>>> Hope this answers your questions, >>>>> Roy >>>>> >>>>> James Gates wrote: >>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >>>>>> OpenSolaris >>>>>> Date: Fri, 22 Feb 2008 11:04:10 -0800 >>>>>> From: Lloyd L Chambers >>>>>> To: James Gates >>>>>> CC: Dan Mick , lsarc-ext@Sun.COM >>>>>> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> >>>>>> <47BC97BB.8020607@sun.com> >>>>>> >>>>>> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> >>>>>> Sounds terrific! >>>>>> llc01 Are there any security issues with the memcached daemons, given >>>>>> that they're listening on ports? If I understand correctly, 10.0.0.x >>>>>> is a LAN address, which exposes the IP only to the local subnet. >>>>>> Still, can you say if there are concerns here? >>>>>> Lloyd Chambers >>>>>> LSARC >>>>>> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>>>>> >>>>>>> I've added the following summary to the details section of the >>>>>>> 1pager: >>>>>>> >>>>>>> memcached is a high-performance, distributed memory object >>>>>>> caching >>>>>>> system, generic in nature, but intended for use in speeding up >>>>>>> dynamic web applications by alleviating database load. >>>>>>> >>>>>>> Danga Interactive developed memcached to enhance the speed of >>>>>>> LiveJournal.com, a site which was already doing 20 million+ >>>>>>> dynamic page views per day for 1 million users with a bunch of >>>>>>> webservers and a bunch of database servers. memcached >>>>>>> dropped the >>>>>>> database load to almost nothing, yielding faster page load >>>>>>> times >>>>>>> for users, better resource utilization, and faster access >>>>>>> to the >>>>>>> databases on a memcache miss. >>>>>>> >>>>>>> How it Works >>>>>>> >>>>>>> First, you start up the memcached daemon on as many spare >>>>>>> machines >>>>>>> as you have. The daemon has no configuration file, just a few >>>>>>> command line options, only 3 or 4 of which you'll likely use: >>>>>>> >>>>>>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>>>>>> >>>>>>> This starts memcached up as a daemon, using 2GB of memory, and >>>>>>> listening on IP 10.0.0.40, port 11211. Because a 32-bit process >>>>>>> can only address 4GB of virtual memory (usually significantly >>>>>>> less, depending on your operating system), if you have a 32-bit >>>>>>> server with 4-64GB of memory using PAE you can just run >>>>>>> multiple >>>>>>> processes on the machine, each using 2 or 3GB of memory. >>>>>>> >>>>>>> Now, in your application, wherever you go to do a database >>>>>>> query, >>>>>>> first check the memcache. If the memcache returns an undefined >>>>>>> object, then go to the database, get what you're looking >>>>>>> for, and >>>>>>> put it in the memcache. >>>>>>> >>>>>>> >>>>>>> Dan Mick wrote: >>>>>>> >>>>>>>> David.Comay@Sun.COM wrote: >>>>>>>> >>>>>>>>>> I have asked Roy to provide a one paragraph summary that I >>>>>>>>>> can add to >>>>>>>>>> the 1pager. But in the meantime, you can read >>>>>>>>>> http://www.danga.com/memcached/ and >>>>>>>>>> http://en.wikipedia.org/wiki/Memcached >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Also as this is a version update to a previous case, you can >>>>>>>>> find out >>>>>>>>> more about memcached by looking at the earlier case, >>>>>>>>> LSARC/2007/385. >>>>>>>>> In particular, >>>>>>>>> >>>>>>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>>>>>> >>>>>>>>> dsc >>>>>>>> >>>>>>>> yes, although one sentence in the current case is pretty low-cost. >>>>>> >>>>>> --- >>>>>> Lloyd L Chambers >>>>>> lloyd.chambers@sun.com >>>>>> Sun Microsystems, Inc >>>> >>>> --- >>>> Lloyd L Chambers >>>> lloyd.chambers@sun.com >>>> Sun Microsystems, Inc >> >> >> --- >> Lloyd L Chambers >> lloyd.chambers@sun.com >> Sun Microsystems, Inc >> >> >> From Roy.Lyseng@sun.com Tue Feb 26 11:00:37 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QJ0bFk010051 for ; Tue, 26 Feb 2008 11:00:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QJ0aQX010060 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Feb 2008 11:00:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWV0043F0SYM900@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 11:00:34 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00L6H0SJRO40@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 11:00:20 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QJ0JbY011642 for ; Tue, 26 Feb 2008 19:00:19 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWV00A010MRWC00@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 19:00:19 +0000 (GMT) Received: from [10.0.0.18] ([80.203.115.203]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWV0086F0SI3J20@fe-emea-10.sun.com>; Tue, 26 Feb 2008 19:00:18 +0000 (GMT) Date: Tue, 26 Feb 2008 19:57:37 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <20080226180347.GX9130@zruty.sfbay.sun.com> Sender: Roy.Lyseng@sun.com To: Danek Duvall Cc: James Gates , lsarc-ext@sun.com Message-id: <47C46121.8030709@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> <20080226180347.GX9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 2456 Danek Duvall wrote: > On Tue, Feb 26, 2008 at 03:11:17PM +0100, Roy Lyseng wrote: > >> Java API: The commitment level for the Java API was classified as >> Volatile in LSARC/2007/385. Based on recent discussions, I am open for >> reclassifying this as Uncommitted, if this is the ARCs opinion. > > Ah, okay. If you're comfortable that the interfaces are sufficiently > stable to be considered Uncommitted, then that's fine, and the ARC would > generally prefer that building blocks like APIs be Uncommitted or better, > but committing too strongly to an interface is problematic, too. Really difficult to say, actually, as this is entirely up to the open-source community. However, the difference between Volatile and Uncommitted seems rather subtle to me :) > >> Dtrace probes: My apologies for not having discussed this. A separate >> mail is being sent to dtrace-discuss@opensolaris.org ASAP. > > Thanks. > >>> As for putting the commands in /usr/memcached/bin, we thought that >>> names like 'memcat', 'memstat', 'memerror', etc. *are* too generic, and >>> were preempting complaints about such commands in /usr/bin. >>> >>> I think the project team would be happy to locate them in /usr/bin. >> I have a concern with the utility names too (I would really see them >> merged into a single utility with subcommands), but of course it is >> simpler for us to put everything into /usr/bin... > > Yeah, I was thinking that they'd make for good subcommands, too. What does > memcached do in its default installation? What do Linux distros do with > these utilities? I would suggest that you ping the memcached community and > see if they'd be willing to accept a change modifying these commands to be > subcommands of a wrapper. But if they've been around a long time and > reasonably consistently delivered in /usr/bin as-is, then they might not be > terribly open to that. > > If they *were* willing to accept such a change, then you could integrate > them as-is in /usr/bin now (as Volatile or Obsolete), and change them > later, when you get the changes integrated in mainline memcached. > > I'm not going to push you too hard in that direction, though. I did discuss a change of names with the author of the libmemcached API, but he did not see the point of it. So I would not bet on this to happen. If this may become a more permanent solution, would you vote for /usr/bin/memXXX or /usr/memcached/bin/memXXX? Roy > > Danek From David.Comay@sun.com Tue Feb 26 12:16:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QKGiIX013229 for ; Tue, 26 Feb 2008 12:16:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QKGg45043015; Tue, 26 Feb 2008 13:16:42 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWV00B074BURZ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:16:42 -0800 (PST) Received: from police.SFBay.Sun.COM ([129.146.228.53]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00LT94BTRI90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:16:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by police.SFBay.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id m1QKGfLf022573; Tue, 26 Feb 2008 12:16:41 -0800 (PST) Date: Tue, 26 Feb 2008 12:16:41 -0800 (PST) From: David.Comay@sun.com Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris In-reply-to: Sender: comay@police.sfbay.sun.com To: Lloyd L Chambers Cc: James Gates , Danek Duvall , lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BC5F15.3050205@sun.com> <20080225211455.GK9130@zruty.sfbay.sun.com> <47C33939.8010305@sun.com> Status: RO Content-Length: 521 > Wouldn't /usr/bin/memcached make more sense then /usr/memcached/bin? LSARC 2007/385 already established a location for memcached /usr/lib/memcached Given that this is a daemon and not a command a user would type, it seems that's the right location in the file system. As for the other commands, assuming they are ones that a user/sysadmin would typically type, /usr/bin seems like the right place for them even with their semi-generic names although I'd like to understand where other OS distros place them. dsc From danek.duvall@sun.com Tue Feb 26 13:41:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QLfxak015973 for ; Tue, 26 Feb 2008 13:41:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QLfwZo023434 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Tue, 26 Feb 2008 13:41:59 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWV00N0189Y2U00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 14:41:58 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00HFG89X4M60@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 26 Feb 2008 14:41:57 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1QLftx6036966; Tue, 26 Feb 2008 13:41:55 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QLfsIU027385; Tue, 26 Feb 2008 13:41:54 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1QLfsHp027384; Tue, 26 Feb 2008 13:41:54 -0800 (PST) Date: Tue, 26 Feb 2008 13:41:54 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C46121.8030709@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com Message-id: <20080226214154.GB9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> <20080226180347.GX9130@zruty.sfbay.sun.com> <47C46121.8030709@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1011 On Tue, Feb 26, 2008 at 07:57:37PM +0100, Roy Lyseng wrote: > Really difficult to say, actually, as this is entirely up to the > open-source community. However, the difference between Volatile and > Uncommitted seems rather subtle to me :) :) Uncommitted gives anyone who's developing against those APIs a bit more breathing room -- they're guaranteed that they're going to continue to work as documented from the point of release in the OS to the time that release is EOLed. The APIs may change incompatibly in the next release of the OS, but even then, we'll try hard to make sure that doesn't happen. > If this may become a more permanent solution, would you vote for > /usr/bin/memXXX or /usr/memcached/bin/memXXX? I'd still go for /usr/bin. If memcached users are tolerant of it, we could introduce a wrapper or name change ourselves, as it's unlikely to be more of a maintenance burden than patching the man pages, but I don't have a sense of how tolerant the community would be of that. Danek From Roy.Lyseng@sun.com Wed Feb 27 04:16:34 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RCGYSj009953 for ; Wed, 27 Feb 2008 04:16:34 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RCGXrE003595; Wed, 27 Feb 2008 04:16:33 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00M01CRJYI00@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 04:16:31 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00KY6CRI4120@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 04:16:31 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RCGUwt011463; Wed, 27 Feb 2008 12:16:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWW00C01C0UI400@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM); Wed, 27 Feb 2008 12:16:30 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWW00KZGCRHKZ40@fe-emea-10.sun.com>; Wed, 27 Feb 2008 12:16:29 +0000 (GMT) Date: Wed, 27 Feb 2008 13:13:46 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <20080226214154.GB9130@zruty.sfbay.sun.com> Sender: Roy.Lyseng@sun.com To: Danek Duvall Cc: James Gates , lsarc-ext@sun.com, dbtg-memcached@sun.com Message-id: <47C553FA.1070507@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> <20080226180347.GX9130@zruty.sfbay.sun.com> <47C46121.8030709@sun.com> <20080226214154.GB9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 1673 Danek Duvall wrote: > On Tue, Feb 26, 2008 at 07:57:37PM +0100, Roy Lyseng wrote: > >> Really difficult to say, actually, as this is entirely up to the >> open-source community. However, the difference between Volatile and >> Uncommitted seems rather subtle to me :) > > :) Uncommitted gives anyone who's developing against those APIs a bit more > breathing room -- they're guaranteed that they're going to continue to work > as documented from the point of release in the OS to the time that release > is EOLed. The APIs may change incompatibly in the next release of the OS, > but even then, we'll try hard to make sure that doesn't happen. The dilemma of dealing with open-source software is that it would be very hard to get a community to sign a contract that they commit interfaces until the next release of their software. Besides, we are releasing Solaris independent of memcached releases, which might prove to be an even bigger problem. So I guess that our strategy can be to declare interfaces as Uncommitted and 1) expect the community to provide compatible interface changes only, or 2) (if 1) does not hold) be prepared to support an older compatible version of memcached until the next minor version of Solaris (5.12). Roy > >> If this may become a more permanent solution, would you vote for >> /usr/bin/memXXX or /usr/memcached/bin/memXXX? > > I'd still go for /usr/bin. If memcached users are tolerant of it, we could > introduce a wrapper or name change ourselves, as it's unlikely to be more > of a maintenance burden than patching the man pages, but I don't have a > sense of how tolerant the community would be of that. > > Danek From carlsonj@phorcys.east.sun.com Wed Feb 27 05:58:16 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RDwGbM011677 for ; Wed, 27 Feb 2008 05:58:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RDwCgQ033460; Wed, 27 Feb 2008 06:58:13 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00A07HH0DC00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 06:58:12 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00HC6HGZ36A0@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 06:58:11 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RDwBXr029612; Wed, 27 Feb 2008 08:58:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RDwBjp029609; Wed, 27 Feb 2008 08:58:11 -0500 (EST) Date: Wed, 27 Feb 2008 08:58:11 -0500 From: James Carlson Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C553FA.1070507@sun.com> To: Roy Lyseng Cc: Danek Duvall , dbtg-memcached@sun.com, lsarc-ext@sun.com, James Gates Message-id: <18373.27763.154877.806122@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> <20080226180347.GX9130@zruty.sfbay.sun.com> <47C46121.8030709@sun.com> <20080226214154.GB9130@zruty.sfbay.sun.com> <47C553FA.1070507@sun.com> Status: RO Content-Length: 1954 Roy Lyseng writes: > The dilemma of dealing with open-source software is that it would be > very hard to get a community to sign a contract that they commit > interfaces until the next release of their software. Besides, we are > releasing Solaris independent of memcached releases, which might prove > to be an even bigger problem. It's not really that much of a dilemma. We don't ask Sun employees to sign any contract, either. The stabilities reflect a number of different issues, all of which need to be taken into account: - the needs of the consumers (there's no use in producing interfaces that the consumers cannot use) - the *likelihood* of incompatible changes - the ability to detect and adapt to changes - the way in which changes are documented for users - how the changes will arrive (bits don't appear in the WOS by magic) It's not just a simple equation where "not paid by SMI" is ever equivalent to "we have no control and no idea when it might change, so it's Volatile." That's exactly the falsehood that sank the usefulness of "External" in the previous interface taxonomy and I'd like to see the same pitfall avoided for "Volatile" -- or we're just going to have to remove that attribute from the taxonomy. > So I guess that our strategy can be to declare interfaces as Uncommitted and > 1) expect the community to provide compatible interface changes only, or > 2) (if 1) does not hold) be prepared to support an older compatible > version of memcached until the next minor version of Solaris (5.12). Yes; that's entirely viable. Depending on the technical details of a specific change, many other responses are also possible. Some incompatible changes are not unwelcome. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Roy.Lyseng@sun.com Wed Feb 27 06:26:00 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1REQ0fD013010 for ; Wed, 27 Feb 2008 06:26:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1REPxFs041028 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Feb 2008 07:25:59 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00D03IRBB100@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 06:25:59 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00845IR9L440@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 06:25:58 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1REPvXk002856 for ; Wed, 27 Feb 2008 14:25:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWW00H01IGRWK00@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 14:25:57 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWW00LOHIQZFE90@fe-emea-09.sun.com>; Wed, 27 Feb 2008 14:25:47 +0000 (GMT) Date: Wed, 27 Feb 2008 15:23:04 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C45B52.7070600@sun.com> Sender: Roy.Lyseng@sun.com To: James Gates Cc: Lloyd L Chambers , lsarc-ext@sun.com Message-id: <47C57248.2030605@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 9779 James Gates wrote: > This case has just been discussed in the weekly LSARC meeting. > > Listening on INADDR_ANY was accepted on the basis that in typical (if > not all) deployments, multiple memcached deamons cooperate in a > distributed environment to provide a very large virtual cache (i.e. > utilizing the memory of many systems). Even if we made it listen only on > loopback interfaces by default, users would immediately change that upon > installation. > > The timer for this case was extended by a week though (it now times out > on 6th March). This is to conclude the discussion for 2 outstanding issues: > > 1) Command names in /usr/bin, and community acceptance of a change to > the names (or a wrapper) I will be happy to front this case against the community, but I am afraid that the process will take far longer time than we have available before the inclusion of memcached into Indiana. Therefore I will seek an interim solution based on the suggestions from Danek where the utilities are indeed put into /usr/bin, but with a Volatile stability classification. > > 2) Acceptance of the Drtace probes A review request was sent to dtrace-discuss late yesterday. Can we give it a 2-day "timeout" (unless there are significant comments)? If these issues were resolved, would it be possible to have an expedited closure of the case? Another issue: it is probably too late to do something about this now, but does there exist a "best practice" document on how to use the /usr/lib/isaexec to pick a 32/64 bit executable based on architecture? The policy document "Recommended Installation Locations for Solaris-compatible Software Components" just refers isaexec(3C), which does not seem to be in widespread use. Thanks, Roy > > > Roy Lyseng wrote: >> >> >> Lloyd L Chambers wrote: >> >>> No, I'm just suggesting that ANY non-loopback port is a risk, and >>> issuing a warning would be worthwhile: >>> >>> NOTE: port dddd is a non-local port. Be sure your firewall setup >>> blocks inappropriate access to this port. >> >> >> Not sure if I appreciate this. Setting up memcached to listen on a >> loopback interface does not make sense, as it is always used in >> machine-to-machine communication. Is there any other product that >> actually do this? >> >> BTW, I guess you really mean interface, and not port? >> >> Thanks, >> Roy >> >>> >>> On Feb 25, 2008, at 12:29 PM, Roy Lyseng wrote: >>> >>>> >>>> >>>> Lloyd L Chambers wrote: >>>> >>>>> Roy, >>>>> Thanks. Does memcached issue a warning in the log if it starts >>>>> listening on ports at risk? >>>> >>>> >>>> No. Do you know a way to identify ports that are at risk? I guess we >>>> would need to communicate with firewalls in order to do this. >>>> >>>> Roy >>>> >>>>> Lloyd >>>>> On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: >>>>> >>>>>> Hi Lloyd, >>>>>> >>>>>> it is indeed possible to configure memcached to listen to local >>>>>> addresses only. If the administrator decides to configure >>>>>> memcached to listen on a publicly available address, a security >>>>>> hole may be opened. >>>>>> >>>>>> There was a substantial discussion on Memcached and security >>>>>> during the first ARC case (LSARC/2007/385). >>>>>> >>>>>> These issues were raised during that case (followed by my responses): >>>>>> >>>>>> Terrence Miller wrote: >>>>>> > tm-1 Can the client and server be on the same machine. If so, >>>>>> > can that system be configured to not accept requests >>>>>> > from the network. >>>>>> >>>>>> The server may be configured to listen on a user-defined port. A >>>>>> firewall may be configured to block that port. >>>>>> >>>>>> You can also configure memcached to listen on a specific >>>>>> interface, in >>>>>> particular the localhost interface. >>>>>> > >>>>>> > tm-2 Can an attack on the server cause it to overload its host >>>>>> > machine. >>>>>> >>>>>> I think that will be very difficult. Processing overhead is very >>>>>> light, >>>>>> it is actually more probable that the attacker will saturate the >>>>>> network. Besides, the memcached server is usually part of a backend >>>>>> system, residing on the same level as a backend database server and >>>>>> having an application server or web server in front. >>>>>> >>>>>> An attacker may attempt to fill the cache with garbage objects that >>>>>> invalidate the "valid" objects. This may become a problem if the >>>>>> attacker gets network access to the memcached server. >>>>>> > >>>>>> > tm-3 Does your documentation state the requirement for >>>>>> protecting >>>>>> > any network connecting clients to server. >>>>>> >>>>>> We do not provide documentation in addition to that provided by the >>>>>> community. >>>>>> > >>>>>> > tm-4 How hard is it to write a firewall rule that blocks all >>>>>> > memcached traffic. >>>>>> >>>>>> The server is usually listening on a single TCP socket, so it >>>>>> should be >>>>>> easy to write a firewall rule that blocks the associated port. As an >>>>>> option, the memcached server may also listen on a UDP socket, but >>>>>> this >>>>>> can also easily be protected. >>>>>> > >>>>>> > tm-5 Will the firewall requirements change with new releases. >>>>>> >>>>>> Impossible to say. The community designs and implements changes to >>>>>> the >>>>>> product. >>>>>> >>>>>> We ended up adding information to release notes that warn >>>>>> administrators about potential security holes when listening on >>>>>> publicly available ports. >>>>>> >>>>>> Hope this answers your questions, >>>>>> Roy >>>>>> >>>>>> James Gates wrote: >>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in >>>>>>> OpenSolaris >>>>>>> Date: Fri, 22 Feb 2008 11:04:10 -0800 >>>>>>> From: Lloyd L Chambers >>>>>>> To: James Gates >>>>>>> CC: Dan Mick , lsarc-ext@Sun.COM >>>>>>> References: <47BC5F15.3050205@sun.com> <47BC8D4A.2000804@sun.com> >>>>>>> <47BC97BB.8020607@sun.com> >>>>>>> >>>>>>> <47BCCD03.9060108@sun.com> <47BDAF65.1030802@sun.com> >>>>>>> Sounds terrific! >>>>>>> llc01 Are there any security issues with the memcached daemons, >>>>>>> given >>>>>>> that they're listening on ports? If I understand correctly, >>>>>>> 10.0.0.x >>>>>>> is a LAN address, which exposes the IP only to the local subnet. >>>>>>> Still, can you say if there are concerns here? >>>>>>> Lloyd Chambers >>>>>>> LSARC >>>>>>> On Feb 21, 2008, at 9:05 AM, James Gates wrote: >>>>>>> >>>>>>>> I've added the following summary to the details section of the >>>>>>>> 1pager: >>>>>>>> >>>>>>>> memcached is a high-performance, distributed memory object >>>>>>>> caching >>>>>>>> system, generic in nature, but intended for use in speeding up >>>>>>>> dynamic web applications by alleviating database load. >>>>>>>> >>>>>>>> Danga Interactive developed memcached to enhance the speed of >>>>>>>> LiveJournal.com, a site which was already doing 20 million+ >>>>>>>> dynamic page views per day for 1 million users with a bunch of >>>>>>>> webservers and a bunch of database servers. memcached >>>>>>>> dropped the >>>>>>>> database load to almost nothing, yielding faster page load >>>>>>>> times >>>>>>>> for users, better resource utilization, and faster access >>>>>>>> to the >>>>>>>> databases on a memcache miss. >>>>>>>> >>>>>>>> How it Works >>>>>>>> >>>>>>>> First, you start up the memcached daemon on as many spare >>>>>>>> machines >>>>>>>> as you have. The daemon has no configuration file, just a few >>>>>>>> command line options, only 3 or 4 of which you'll likely use: >>>>>>>> >>>>>>>> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >>>>>>>> >>>>>>>> This starts memcached up as a daemon, using 2GB of memory, and >>>>>>>> listening on IP 10.0.0.40, port 11211. Because a 32-bit >>>>>>>> process >>>>>>>> can only address 4GB of virtual memory (usually significantly >>>>>>>> less, depending on your operating system), if you have a >>>>>>>> 32-bit >>>>>>>> server with 4-64GB of memory using PAE you can just run >>>>>>>> multiple >>>>>>>> processes on the machine, each using 2 or 3GB of memory. >>>>>>>> >>>>>>>> Now, in your application, wherever you go to do a database >>>>>>>> query, >>>>>>>> first check the memcache. If the memcache returns an undefined >>>>>>>> object, then go to the database, get what you're looking >>>>>>>> for, and >>>>>>>> put it in the memcache. >>>>>>>> >>>>>>>> >>>>>>>> Dan Mick wrote: >>>>>>>> >>>>>>>>> David.Comay@Sun.COM wrote: >>>>>>>>> >>>>>>>>>>> I have asked Roy to provide a one paragraph summary that I >>>>>>>>>>> can add to >>>>>>>>>>> the 1pager. But in the meantime, you can read >>>>>>>>>>> http://www.danga.com/memcached/ and >>>>>>>>>>> http://en.wikipedia.org/wiki/Memcached >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also as this is a version update to a previous case, you can >>>>>>>>>> find out >>>>>>>>>> more about memcached by looking at the earlier case, >>>>>>>>>> LSARC/2007/385. >>>>>>>>>> In particular, >>>>>>>>>> >>>>>>>>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>>>>>>>> >>>>>>>>>> dsc >>>>>>>>> >>>>>>>>> yes, although one sentence in the current case is pretty low-cost. >>>>>>> >>>>>>> --- >>>>>>> Lloyd L Chambers >>>>>>> lloyd.chambers@sun.com >>>>>>> Sun Microsystems, Inc >>>>> >>>>> --- >>>>> Lloyd L Chambers >>>>> lloyd.chambers@sun.com >>>>> Sun Microsystems, Inc >>> >>> >>> --- >>> Lloyd L Chambers >>> lloyd.chambers@sun.com >>> Sun Microsystems, Inc >>> >>> >>> From danek.duvall@sun.com Wed Feb 27 07:21:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RFLrHD013659 for ; Wed, 27 Feb 2008 07:21:53 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1RFLex0014148; Wed, 27 Feb 2008 23:21:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00G0NLCDNT00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 08:21:49 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00H9TLCC3DF0@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 08:21:49 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RFLkQg042735; Wed, 27 Feb 2008 07:21:46 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RFLksU001686; Wed, 27 Feb 2008 07:21:46 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RFLjBE001685; Wed, 27 Feb 2008 07:21:46 -0800 (PST) Date: Wed, 27 Feb 2008 07:21:45 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C553FA.1070507@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com, dbtg-memcached@sun.com Message-id: <20080227152145.GM11899@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C33A0B.4040902@sun.com> <47C41E05.1080006@sun.com> <20080226180347.GX9130@zruty.sfbay.sun.com> <47C46121.8030709@sun.com> <20080226214154.GB9130@zruty.sfbay.sun.com> <47C553FA.1070507@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 443 On Wed, Feb 27, 2008 at 01:13:46PM +0100, Roy Lyseng wrote: > So I guess that our strategy can be to declare interfaces as Uncommitted > and > 1) expect the community to provide compatible interface changes only, or > 2) (if 1) does not hold) be prepared to support an older compatible version > of memcached until the next minor version of Solaris (5.12). Yup. This is precisely why free software isn't "free" (zero work) for us. Danek From danek.duvall@sun.com Wed Feb 27 14:39:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RMdUK9007422 for ; Wed, 27 Feb 2008 14:39:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RMdLCP007389 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Feb 2008 22:39:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00E035LRVF00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 14:39:27 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00C7D5LQS4E0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 14:39:26 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RMdNJP034041; Wed, 27 Feb 2008 14:39:23 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RMdNGZ006206; Wed, 27 Feb 2008 14:39:23 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RMdNxp006205; Wed, 27 Feb 2008 14:39:23 -0800 (PST) Date: Wed, 27 Feb 2008 14:39:22 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C57248.2030605@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com, Lloyd L Chambers Message-id: <20080227223922.GO9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> <47C57248.2030605@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1353 On Wed, Feb 27, 2008 at 03:23:04PM +0100, Roy Lyseng wrote: > > 1) Command names in /usr/bin, and community acceptance of a change to > > the names (or a wrapper) > > I will be happy to front this case against the community, but I am > afraid that the process will take far longer time than we have available > before the inclusion of memcached into Indiana. Therefore I will seek an > interim solution based on the suggestions from Danek where the utilities > are indeed put into /usr/bin, but with a Volatile stability classification. Okay by me (of course). > > 2) Acceptance of the Drtace probes > > A review request was sent to dtrace-discuss late yesterday. Can we give > it a 2-day "timeout" (unless there are significant comments)? Seems fair, but do make sure they know it's a short timeout. > If these issues were resolved, would it be possible to have an expedited > closure of the case? Sure. > Another issue: it is probably too late to do something about this now, > but does there exist a "best practice" document on how to use the > /usr/lib/isaexec to pick a 32/64 bit executable based on architecture? Not really. What is it you need to know? Hard link your executable to /usr/lib/isaexec, put your 32-bit binaries in i86 and sparcv7 and yor 64-bit binaries in amd64 and sparcv9 and you should be good to go. Danek From Roy.Lyseng@sun.com Wed Feb 27 15:23:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RNMxkR009809 for ; Wed, 27 Feb 2008 15:23:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RNMurj023732 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Feb 2008 23:22:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX004077M81A00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 15:22:56 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00HVL7M7L7C0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 15:22:56 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RNMtaP008757 for ; Wed, 27 Feb 2008 23:22:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX002017KGD800@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 23:22:55 +0000 (GMT) Received: from [10.0.0.18] ([80.203.115.203]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00L1Z7M65O20@fe-emea-09.sun.com>; Wed, 27 Feb 2008 23:22:54 +0000 (GMT) Date: Thu, 28 Feb 2008 00:20:11 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <20080227223922.GO9130@zruty.sfbay.sun.com> Sender: Roy.Lyseng@sun.com To: Danek Duvall Cc: James Gates , lsarc-ext@sun.com, Lloyd L Chambers Message-id: <47C5F02B.7090801@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> <47C57248.2030605@sun.com> <20080227223922.GO9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 828 Danek Duvall wrote: >>> 2) Acceptance of the Drtace probes >> A review request was sent to dtrace-discuss late yesterday. Can we give >> it a 2-day "timeout" (unless there are significant comments)? > > Seems fair, but do make sure they know it's a short timeout. Will do. > >> Another issue: it is probably too late to do something about this now, >> but does there exist a "best practice" document on how to use the >> /usr/lib/isaexec to pick a 32/64 bit executable based on architecture? > > Not really. What is it you need to know? Hard link your executable to > /usr/lib/isaexec, put your 32-bit binaries in i86 and sparcv7 and yor > 64-bit binaries in amd64 and sparcv9 and you should be good to go. As simple as we thought it do be then... Do we need additional ARCing in case we do this? Roy > > Danek From danek.duvall@sun.com Wed Feb 27 16:13:50 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S0Dn4e011778 for ; Wed, 27 Feb 2008 16:13:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1S0DiKu015716 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Thu, 28 Feb 2008 00:13:48 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00A0J9YZUA00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 27 Feb 2008 17:13:47 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00CJC9YYX3E0@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 27 Feb 2008 17:13:46 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1S0DhNO025096; Wed, 27 Feb 2008 16:13:43 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1S0DhCq007715; Wed, 27 Feb 2008 16:13:43 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1S0DgSD007714; Wed, 27 Feb 2008 16:13:43 -0800 (PST) Date: Wed, 27 Feb 2008 16:13:40 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C5F02B.7090801@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com, Lloyd L Chambers Message-id: <20080228001340.GP9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> <47C57248.2030605@sun.com> <20080227223922.GO9130@zruty.sfbay.sun.com> <47C5F02B.7090801@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 931 On Thu, Feb 28, 2008 at 12:20:11AM +0100, Roy Lyseng wrote: >>> Another issue: it is probably too late to do something about this now, >>> but does there exist a "best practice" document on how to use the >>> /usr/lib/isaexec to pick a 32/64 bit executable based on architecture? >> >> Not really. What is it you need to know? Hard link your executable to >> /usr/lib/isaexec, put your 32-bit binaries in i86 and sparcv7 and yor >> 64-bit binaries in amd64 and sparcv9 and you should be good to go. > > As simple as we thought it do be then... Do we need additional ARCing in > case we do this? You should mention it in ARC materials, but this could be done in a follow-up message to 2008/126, just saying that you're making this obvious modification. Alternately, you could file a self-approval case with the same effect (if, for instance, you needed a different ARC case number). Either way, it's pretty trivial. Danek From Roy.Lyseng@sun.com Thu Feb 28 02:32:28 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SAWR5u028255 for ; Thu, 28 Feb 2008 02:32:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SAWRLF002672 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 28 Feb 2008 02:32:27 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWY00F092M3W800@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 28 Feb 2008 03:32:27 -0700 (MST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00A5M2M2QV30@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 28 Feb 2008 03:32:27 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1SAWQDv009022 for ; Thu, 28 Feb 2008 10:32:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY0010121WK400@fe-emea-10.sun.com> (original mail from Roy.Lyseng@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 28 Feb 2008 10:32:26 +0000 (GMT) Received: from [129.159.112.178] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY00DHT2M03R90@fe-emea-10.sun.com>; Thu, 28 Feb 2008 10:32:24 +0000 (GMT) Date: Thu, 28 Feb 2008 11:29:41 +0100 From: Roy Lyseng Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <20080228001340.GP9130@zruty.sfbay.sun.com> Sender: Roy.Lyseng@sun.com To: Danek Duvall Cc: James Gates , lsarc-ext@sun.com, Lloyd L Chambers Message-id: <47C68D15.80800@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BF1CFB.4040004@sun.com> <47C29686.9090403@sun.com> <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> <47C57248.2030605@sun.com> <20080227223922.GO9130@zruty.sfbay.sun.com> <47C5F02B.7090801@sun.com> <20080228001340.GP9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 1047 Danek Duvall wrote: > On Thu, Feb 28, 2008 at 12:20:11AM +0100, Roy Lyseng wrote: > >>>> Another issue: it is probably too late to do something about this now, >>>> but does there exist a "best practice" document on how to use the >>>> /usr/lib/isaexec to pick a 32/64 bit executable based on architecture? >>> Not really. What is it you need to know? Hard link your executable to >>> /usr/lib/isaexec, put your 32-bit binaries in i86 and sparcv7 and yor >>> 64-bit binaries in amd64 and sparcv9 and you should be good to go. >> As simple as we thought it do be then... Do we need additional ARCing in >> case we do this? > > You should mention it in ARC materials, but this could be done in a > follow-up message to 2008/126, just saying that you're making this obvious > modification. Alternately, you could file a self-approval case with the > same effect (if, for instance, you needed a different ARC case number). > > Either way, it's pretty trivial. Yepp. But I wonder why there is no man page for isaexec(1m) ;) Roy > > Danek From danek.duvall@sun.com Thu Feb 28 09:18:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SHIQa5008772 for ; Thu, 28 Feb 2008 09:18:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1SHIJXr006062 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Thu, 28 Feb 2008 17:18:26 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWY0007VLEMAU00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 28 Feb 2008 10:18:22 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00IEBLEJQX50@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 28 Feb 2008 10:18:19 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1SHIGZ3051908; Thu, 28 Feb 2008 09:18:16 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1SHIGAw015035; Thu, 28 Feb 2008 09:18:16 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1SHIFt4015034; Thu, 28 Feb 2008 09:18:15 -0800 (PST) Date: Thu, 28 Feb 2008 09:18:15 -0800 From: Danek Duvall Subject: Re: [Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris] In-reply-to: <47C68D15.80800@sun.com> To: Roy Lyseng Cc: James Gates , lsarc-ext@sun.com, Lloyd L Chambers Message-id: <20080228171815.GR9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C3251E.1080300@sun.com> <910AF99A-392B-49FF-8941-7272BCEEEB4D@Sun.COM> <47C4538A.80707@sun.com> <47C45B52.7070600@sun.com> <47C57248.2030605@sun.com> <20080227223922.GO9130@zruty.sfbay.sun.com> <47C5F02B.7090801@sun.com> <20080228001340.GP9130@zruty.sfbay.sun.com> <47C68D15.80800@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 364 On Thu, Feb 28, 2008 at 11:29:41AM +0100, Roy Lyseng wrote: > Yepp. But I wonder why there is no man page for isaexec(1m) ;) Dunno. Looks like it was introduced in PSARC/1997/220, but not explicitly exported in the interface table (only isaexec(3c) was). Might be worth filing a bug to get a simple manpage, but I doubt it'd end up being high priority. Danek From Roy.Lyseng@sun.com Fri Feb 29 10:06:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TI624N020336 for ; Fri, 29 Feb 2008 10:06:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1TI5vXB016729; Sat, 1 Mar 2008 02:06:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX000A0JI9YQ300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 10:05:58 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX00068WI9V70D0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 10:05:56 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TI5t7q012112; Fri, 29 Feb 2008 18:05:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000701I4EUS00@fe-emea-09.sun.com> (original mail from Roy.Lyseng@Sun.COM); Fri, 29 Feb 2008 18:05:55 +0000 (GMT) Received: from [129.159.115.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX0002DAI9RXOB0@fe-emea-09.sun.com>; Fri, 29 Feb 2008 18:05:53 +0000 (GMT) Date: Fri, 29 Feb 2008 19:02:59 +0100 From: Roy Lyseng Subject: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris Sender: Roy.Lyseng@sun.com To: James Gates Cc: lsarc-ext@sun.com, dbtg-memcached@sun.com Message-id: <47C848D3.9080703@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_htv6+iExKOum3nUd0dKWtQ)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Status: RO Content-Length: 18631 This is a multi-part message in MIME format. --Boundary_(ID_htv6+iExKOum3nUd0dKWtQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, here is the updated one-pager and Dtrace scripts. One pager: - Moved utilities from /usr/memcached/bin to /usr/bin. - Java API: stability raised from Volatile to Uncommitted - Hard link from /usr/lib/memcached to /usr/lib/isaexec and executables in /usr/lib/<32>/memcached and /usr/lib/<64>/memcached (yes, installation works!) Dtrace script has been updated according to comments from dtrace-discuss. Thank you, Roy --Boundary_(ID_htv6+iExKOum3nUd0dKWtQ) Content-type: text/plain; name=1pager2.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=1pager2.txt Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: memcached 1.2.5 to be included in OpenSolaris 1.2. Name of Document Author/Supplier: Roy Lyseng 1.3. Date of This Document: 02/20/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Webstack 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: erlend.dahl@sun.com 1.5.2. Responsible Engineer: roy.lyseng@sun.com 1.5.4. Interest List: memcached-interest@sun.com 2. Project Summary 2.1. Project Description: Update memcached in OpenSolaris from version 1.2.2 to 1.2.5. Add Java API version 2.0. Add C API libmemcached version 0.16. Remove C API libmemcache version 1.4.0. memcached is performance enhanced for multicore computers. Add Dtrace probes to memcached. Add 64-bit version of memcached. Refer also ARC case LSARC/2007/385 that added memcached 1.2.2. 2.2. Risks and Assumptions: Replacing libmemcache with libmemcached is a risk if somebody depend on libmemcache. However, we think the community for this API is small. 3. Business Summary 3.1. Problem Area: Increase performance on Sun hardware. Increase supported cache size beyond limit enforced by 32-bit arch. Supply a richer set of client interfaces. Remove interfaces that are not actively maintained. 3.6. How will you know when you are done?: memcached on Niagara is competitive to other offerings. 4. Technical Description: 4.1 Details The update to the memcached daemon is mostly a version upgrade. An additional option is made to enhance large memory utilization. The Java API was described in LSARC/2007/385, but was not included at that time due to missing OSR approval (time constrained). The libmemcached C API includes a set of binary utility programs. These are all placed in the /usr/bin directory and are given a Volatile stability classification. They are only meant for ad-hoc use. We will seek a future action to merge these into a single utility program invoked with subcommands. Their man pages are placed in /usr/share/man. The library exists in 32 and 64 bit versions, but the utilities are 32 bit only. Dtrace probes are described in attached memcached_dtrace.d. 4.5. Interfaces: Id Interface name Stability Comment ------------------------------------------------------------------ E10 libmemcache C API Volatile Removed E12 Java API Uncommitted Stability increased from Volatile Was never delivered in 2007/385. E18 libmemcached C API Uncommitted New in Solaris E20 daemon command line Uncommitted New option: -L enable large pages E27 Dtrace probes Uncommitted Probes added E31 memcat Volatile libmemcached utility E32 memcp Volatile libmemcached utility E33 memerror Volatile libmemcached utility E34 memflush Volatile libmemcached utility E35 memrm Volatile libmemcached utility E36 memslap Volatile libmemcached utility E37 memstat Volatile libmemcached utility 4.6. Doc Impact: Need man pages for new libmemcached C API Man page update for command line options must be updated for -L 4.7. Admin/Config Impact: Only if application tuning is required. 4.8. HA Impact: None 4.9. I18N/L10N Impact: None 4.10. Packaging & Delivery: New packages are added for C API and Java API, see appendix. 4.11. Security Impact: No changes. 4.12. Dependencies: No changes. 5. Reference Documents: 6. Resources and Schedule: 6.1. Projected Availability: CY 2008 - Q1 6.2. Cost of Effort: 1.5 persons in engineering 1 person in QE/QA 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.4.7. Target RTI Date/Release: SNV build 86 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris Packages SUNWmemcached - [usr] Server package SUNWmemcachedr - [root] SMF files SUNWlibmemcached - [usr] libmemcached C API SUNWmemcached-java - [usr] Memcached Java API File structure (SUNWmemcached) /usr/lib/memcached (hard link to /usr/lib/isaexec) /usr/lib//memcached /usr/lib//memcached /usr/share/man/man1m/memcached.1m File structure (SUNWmemcachedr) /lib/svc/method/memcached /var/svc/manifest/application/database/memcached.xml File structure (SUNWmemcached-java) /usr/share/lib/java/java_memcached_release_2.0.jar /usr/share/lib/java/javadoc/memcached-java/* File structure (SUNWlibmemcached) /usr/lib/libmemcached.so.2.0.0 /usr/lib/libmemcached.so.2 -> /usr/lib/libmemcached.so.2.0.0 /usr/lib/libmemcached.so -> /usr/lib/libmemcached.so.2.0.0 /usr/lib//libmemcached.so.2.0.0 /usr/lib//libmemcached.so.2 -> /usr/lib//libmemcached.so.2.0.0 /usr/lib//libmemcached.so -> /usr/lib//libmemcached.so.2.0.0 /usr/include/libmemcached/memcached.h /usr/bin/memcat /usr/bin/memcp /usr/bin/memerror /usr/bin/memflush /usr/bin/memrm /usr/bin/memslap /usr/bin/memstat /usr/share/man/man1/memcat.1 /usr/share/man/man1/memcp.1 /usr/share/man/man1/memerror.1 /usr/share/man/man1/memflush.1 /usr/share/man/man1/memrm.1 /usr/share/man/man1/memslap.1 /usr/share/man/man1/memstat.1 /usr/share/man/man3libmemcached/libmemcached.3libmemcached /usr/share/man/man3libmemcached/libmemcached_examples.3libmemcached /usr/share/man/man3libmemcached/memcached_add.3libmemcached /usr/share/man/man3libmemcached/memcached_add_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_append.3libmemcached /usr/share/man/man3libmemcached/memcached_append_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_behavior_get.3libmemcached /usr/share/man/man3libmemcached/memcached_behavior_set.3libmemcached /usr/share/man/man3libmemcached/memcached_callback_get.3libmemcached /usr/share/man/man3libmemcached/memcached_callback_set.3libmemcached /usr/share/man/man3libmemcached/memcached_cas.3libmemcached /usr/share/man/man3libmemcached/memcached_cas_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_clone.3libmemcached /usr/share/man/man3libmemcached/memcached_create.3libmemcached /usr/share/man/man3libmemcached/memcached_decrement.3libmemcached /usr/share/man/man3libmemcached/memcached_delete.3libmemcached /usr/share/man/man3libmemcached/memcached_delete_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch_execute.3libmemcached /usr/share/man/man3libmemcached/memcached_fetch_result.3libmemcached /usr/share/man/man3libmemcached/memcached_free.3libmemcached /usr/share/man/man3libmemcached/memcached_get.3libmemcached /usr/share/man/man3libmemcached/memcached_get_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_increment.3libmemcached /usr/share/man/man3libmemcached/memcached_lib_version.3libmemcached /usr/share/man/man3libmemcached/memcached_mget.3libmemcached /usr/share/man/man3libmemcached/memcached_mget_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_prepend.3libmemcached /usr/share/man/man3libmemcached/memcached_prepend_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_quit.3libmemcached /usr/share/man/man3libmemcached/memcached_replace.3libmemcached /usr/share/man/man3libmemcached/memcached_replace_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_server_add.3libmemcached /usr/share/man/man3libmemcached/memcached_server_count.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_append.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_count.3libmemcached /usr/share/man/man3libmemcached/memcached_server_list_free.3libmemcached /usr/share/man/man3libmemcached/memcached_server_push.3libmemcached /usr/share/man/man3libmemcached/memcached_servers_parse.3libmemcached /usr/share/man/man3libmemcached/memcached_set.3libmemcached /usr/share/man/man3libmemcached/memcached_set_by_key.3libmemcached /usr/share/man/man3libmemcached/memcached_stat.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_get_keys.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_get_value.3libmemcached /usr/share/man/man3libmemcached/memcached_stat_servername.3libmemcached /usr/share/man/man3libmemcached/memcached_strerror.3libmemcached /usr/share/man/man3libmemcached/memcached_verbosity.3libmemcached /usr/share/man/man3libmemcached/memcached_version.3libmemcached is replaced with sparcv7 for Sparc 32 bit architecture and with i86 for Intel/AMD 32 bit architecture. is replaced with sparcv9 for Sparc 64 bit architecture and with amd64 for AMD 64 bit architecture. --Boundary_(ID_htv6+iExKOum3nUd0dKWtQ) Content-type: text/plain; name=memcached_dtrace.d Content-transfer-encoding: 7BIT Content-disposition: inline; filename=memcached_dtrace.d provider memcached { /** * Fired when a connection object is allocated from the connection pool * @param connid the connection id */ probe conn__allocate(int connid); /** * Fired when a connection object is released back to the connection pool * @param connid the connection id */ probe conn__release(int connid); /** * Fired when a new connection object is being created (there is no more * connection objects in the connection pool) * @param ptr pointer to the connection object */ probe conn__create(void *ptr); /** * Fired when a connection object is being destroyed ("released back to * the memory subsystem") * @param ptr pointer to the connection object */ probe conn__destroy(void *ptr); /** * Fired when a connection is dispatched from the "main thread" to a * worker thread. * @param connid the connection id * @param threadid the thread id */ probe conn__dispatch(int connid, int threadid); /** * Allocate memory from the slab allocator * @param size the requested size * @param slabclass the allocation will be fulfilled in this class * @param slabsize the size of each item in this class * @param ptr pointer to allocated memory */ probe slabs__allocate(int size, int slabclass, int slabsize, void* ptr); /** * Failed to allocate memory (out of memory) * @param size the requested size * @param slabclass the class that failed to fulfill the request */ probe slabs__allocate__failed(int size, int slabclass); /** * Fired when a slab class needs more space * @param slabclass class that needs more memory */ probe slabs__slabclass__allocate(int slabclass); /** * Failed to allocate memory (out of memory) * @param slabclass the class that failed grab more memory */ probe slabs__slabclass__allocate__failed(int slabclass); /** * Release memory * @param size the size of the memory * @param slabclass the class the memory belongs to * @param ptr pointer to the memory to release */ probe slabs__free(int size, int slabclass, void* ptr); /** * Fired when the when we have searched the hash table for a named key. * These two elements provide an insight in how well the hash function * functions. Long traversals are a sign of a less optimal function, * wasting cpu capacity. * * @param key the key searched for * @param depth the depth in the list of hash table */ probe assoc__find(const char *key, int depth); /** * Fired when a new item has been inserted. * @param key the key just inserted * @param nokeys the total number of keys currently being stored, * including the key for which insert was called. */ probe assoc__insert(const char *key, int nokeys); /** * Fired when a new item has been removed. * @param key the key just deleted * @param nokeys the total number of keys currently being stored, * excluding the key for which delete was called. */ probe assoc__delete(const char *key, int nokeys); /** * Fired when an item is being linked in the cache * @param key the items key * @param size the size of the data */ probe item__link(const char *key, int size); /** * Fired when an item is being deleted * @param key the items key * @param size the size of the data */ probe item__unlink(const char *key, int size); /** * Fired when the refcount for an item is reduced * @param key the items key * @param size the size of the data */ probe item__remove(const char *key, int size); /** * Fired when the "last refenced" time is updated * @param key the items key * @param size the size of the data */ probe item__update(const char *key, int size); /** * Fired when an item is bein replaced with another item * @param oldkey the key of the item to replace * @param oldsize the size of the old item * @param newkey the key of the new item * @param newsize the size of the new item */ probe item__replace(const char *oldkey, int oldsize, const char *newkey, int newsize); /** * Fired when the processing of a command starts * @param connid the connection id * @param request the incomming request * @param size the size of the request */ probe process__command__start(int connid, const void *request, int size); /** * Fired when the processing of a command is done * @param connid the connection id * @param respnse the response to send back to the client * @param size the size of the response */ probe process__command__end(int connid, const void *response, int size); /** * Fired for a get-command * @param connid connection id * @param key requested key * @param size size of the key's data (or -1 if not found) */ probe command__get(int connid, const char *key, int size); /** * Fired for a gets command * @param connid connection id * @param key requested key * @param size size of the key's data (or -1 if not found) * @param casid the casid for the item */ probe command__gets(int connid, const char *key, int size, int64_t casid); /** * Fired for a add-command * @param connid connection id * @param key requested key * @param size the new size of the key's data (or -1 if not found) */ probe command__add(int connid, const char *key, int size); /** * Fired for a set-command * @param connid connection id * @param key requested key * @param size the new size of the key's data (or -1 if not found) */ probe command__set(int connid, const char *key, int size); /** * Fired for a replace-command * @param connid connection id * @param key requested key * @param size the new size of the key's data (or -1 if not found) */ probe command__replace(int connid, const char *key, int size); /** * Fired for a prepend-command * @param connid connection id * @param key requested key * @param size the new size of the key's data (or -1 if not found) */ probe command__prepend(int connid, const char *key, int size); /** * Fired for a append-command * @param connid connection id * @param key requested key * @param size the new size of the key's data (or -1 if not found) */ probe command__append(int connid, const char *key, int size); /** * Fired for a cas-command * @param connid connection id * @param key requested key * @param size size of the key's data (or -1 if not found) * @param casid the cas id requested */ probe command__cas(int connid, const char *key, int size, int64_t casid); /** * Fired for incr command * @param connid connection id * @param key the requested key * @param val the new value */ probe command__incr(int connid, const char *key, int64_t val); /** * Fired for decr command * @param connid connection id * @param key the requested key * @param val the new value */ probe command__decr(int connid, const char *key, int64_t val); /** * Fired for a delete command * @param connid connection id * @param key the requested key * @param exptime the expiry time */ probe command__delete(int connid, const char *key, long exptime); }; #pragma D attributes Unstable/Unstable/Common provider memcached provider #pragma D attributes Private/Private/Common provider memcached module #pragma D attributes Private/Private/Common provider memcached function #pragma D attributes Unstable/Unstable/Common provider memcached name #pragma D attributes Unstable/Unstable/Common provider memcached args --Boundary_(ID_htv6+iExKOum3nUd0dKWtQ)-- From james.gates@sun.com Fri Mar 7 12:12:14 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m27KCEa6014261 for ; Fri, 7 Mar 2008 12:12:14 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m27KCCi1022358 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 7 Mar 2008 12:12:13 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXD00D05MSCRJ00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 07 Mar 2008 13:12:12 -0700 (MST) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXD000UVMSA11B0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 07 Mar 2008 13:12:10 -0700 (MST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m27KC9ch027923; Fri, 07 Mar 2008 20:12:09 +0000 (GMT) Received: from [192.168.1.102] (vpn-129-150-65-175.East.Sun.COM [129.150.65.175]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m27KC0ZX007891; Fri, 07 Mar 2008 20:12:05 +0000 (GMT) Date: Fri, 07 Mar 2008 15:11:27 -0500 From: James Gates Subject: LSARC case approved 03/06/2008 (2008/126) To: Roy Lyseng , lsarc-ext@sun.com Message-id: <47D1A16F.2060501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 211 Name: memcached 1.2.5 to be included in OpenSolaris Submitter: Roy Lyseng Owner: James Gates Interest: Status: closed approved fast-track 03/06/2008 Exposure: open Comment: