Planet Samba

Here you will find the personal blogs of Samba developers (for those that keep them). More information about members can also be found on the Samba Team page.

July 29, 2014


Pettycoin Alpha01 Tagged

As all software, it took longer than I expected, but today I tagged the first version of pettycoin.  Now, lots more polish and features, but at least there’s something more than the git repo for others to look at!

July 29, 2014 07:53 AM

July 21, 2014


What is preloading?

by Jakub Hrozek and Andreas Schneider

The LD_PRELOAD trick!

Preloading is a feature of the dynamic linker (ld). It is a available on most Unix system and allows to load a user specified, shared library before all other shared libraries which are linked to an executable.

Library pre-loading is most commonly used when you need a custom version of a library function to be called. You might want to implement your own malloc(3) and free(3) functions that would perform a rudimentary leak checking or memory access control for example, or you might want to extend the I/O calls to dump data when reverse engineering a binary blob. In this case, the library to be preloaded would implement the functions you want to override with prelinking. Only functions of dynamically loaded libraries can be overridden. You’re not able to override a function the application implements by itself or links statically with.

The library to preload is defined by the environment variable LD_PRELOAD, such as The symbols of the preloaded library are bound first, before other linked shared libraries.
Lets look into symbol binding in more details. If your application calls a function, then the linker looks if it is available in the application itself first. If the symbol is not found, the linker checks all preloaded libraries and only then all the libraries which have been linked to your application. The shared libraries are searched in the order which has been given during compilation and linking. You can find out the linking order by calling 'ldd /path/to/my/applicaton'. If you’re interested how the linker is searching for the symbols it needs or if you want do debug if the symbol of your preloaded library is used correctly, you can do that by enabling tracing in the linker.

A simple example would be 'LD_DEBUG=symbols ls'. You can find more details about debugging with the linker in the manpage: 'man'.


Your application uses the function open(2).

  • Your application doesn’t implement it.
  • provides open(2).
  • The linked provides open(2).

=> The open(2) symbol from gets bound!

The wrappers used for creating complex testing environments of the cwrap project use preloading to supply their own variants of several system or library calls suitable for unit testing of networked software or privilege separation. For example, one wrapper includes its version of most of the standard API used to communicate over sockets that routes the communication over local sockets.

flattr this!

July 21, 2014 10:38 AM

July 17, 2014


API Bug of the Week: getsockname().

A “non-blocking” IPv6 connect() call was in fact, blocking.  Tracking that down made me realize the IPv6 address was mostly random garbage, which was caused by this function:

bool get_fd_addr(int fd, struct protocol_net_address *addr)
   union {
      struct sockaddr sa;
      struct sockaddr_in in;
      struct sockaddr_in6 in6;
   } u;
   socklen_t len = sizeof(len);
   if (getsockname(fd, &, &len) != 0)
      return false;

The bug: “sizeof(len)” should be “sizeof(u)”.  But when presented with a too-short length, getsockname() truncates, and otherwise “succeeds”; you have to check the resulting len value to see what you should have passed.

Obviously an error return would be better here, but the writable len arg is pretty useless: I don’t know of any callers who check the length return and do anything useful with it.  Provide getsocklen() for those who do care, and have getsockname() take a size_t as its third arg.

Oh, and the blocking?  That was because I was calling “fcntl(fd, F_SETFD, …)” instead of “F_SETFL”!

July 17, 2014 03:31 AM

July 09, 2014


Samba AD DC in Fedora and RHEL

Several people asked me about the status about the Active Directory Domain Controller support of Samba in Fedora. As Fedora and RHEL are using MIT Kerberos implementation as its Kerberos infrastructure of choice, the Samba Active Directory Domain Controller implementation is not available with MIT Kereberos at the moment. But we are working on it!

Günther Deschner and I gave a talk at the SambaXP conference about our development efforts in this direction:

The road to MIT KRB5 support

I hope this helps to understand that this is a huge task.

flattr this!

July 09, 2014 09:05 AM

July 02, 2014


Samba Server-Side Copy Offload

I recently implemented server-side copy offload support for Samba 4.1, along with Btrfs filesystem specific enhancements. This video compares server-side copy performance with traditional copy methods.

A few notes on the demonstration:
  • The Windows Server 2012 client and Samba server are connected via an old 100 Mb/s switch, which obviously acts as a network throughput bottleneck in the traditional copy demonstration.
  • The Samba server resembles the 4.1.0 code-base, but includes an extra patch to disable server-side copy requests on the regular share.

Many thanks to:
  • My colleagues at SUSE Linux, for supporting my implementation efforts.
  • The Samba Team, particularly Metze and Jeremy, for reviewing the code.
  • Kdenlive developers, for writing a great video editing suite.

Update (July, 2014): Usage is now fully documented on the Samba Wiki.

    July 02, 2014 06:21 PM

    June 21, 2014


    Alternate Blog for my Pettycoin Work

    I decided to use github for pettycoin, and tested out their blogging integration (summary: it’s not very integrated, but once set up, Jekyll is nice).  I’m keeping a blow-by-blow development blog over there.

    June 21, 2014 12:14 AM

    June 16, 2014


    Rusty Goes on Sabbatical, June to December

    At I spoke about my pre-alpha implementation of Pettycoin, but progress since then has been slow.  That’s partially due to yak shaving (like rewriting ccan/io library), partially reimplementation of parts I didn’t like, and partially due to the birth of my son, but mainly because I have a day job which involves working on Power 8 KVM issues for IBM.  So Alex convinced me to take 6 months off from the day job, and work 4 days a week on pettycoin.

    I’m going to be blogging my progress, so expect several updates a week.  The first few alpha releases will be useless for doing any actual transactions, but by the first beta the major pieces should be in place…

    June 16, 2014 08:50 AM

    June 11, 2014


    Using the Azure File Service on Linux

    The Microsoft Azure File Service is a new SMB shared-storage service offered on the Microsoft Azure public cloud.

    The service allows for the instant provisioning of file shares for private access by cloud provisioned VMs using the SMB 2.1 protocol, and additionally supports public access via a new REST interface.

    Linux VMs deployed on Azure can make use of this service using the Linux Kernel CIFS client. The kernel client must be configured to support and use the SMB 2.1 protocol dialect:
    • CONFIG_CIFS_SMB2 must be enabled in the kernel configuration at build time
      • Use
        # zcat /proc/config.gz | grep CONFIG_CIFS_SMB2
        to check this on a running system.
    • The vers=2.1 mount.cifs parameter must be provided at mount time.
    • Furthermore, the Azure storage account and access key must be provided as username and password.

    # mount.cifs -o vers=2.1,user=smb // /share/
    Password for smb@// ******...
    # df -h /share/
    Filesystem Size Used Avail Use% Mounted on
    // 5.0T 0 5.0T 0% /share

    This feature will be supported with the upcoming release of SUSE Linux Enterprise Server 12, and future openSUSE releases.

    Disclaimer: I work in the Labs department at SUSE.

    June 11, 2014 09:13 PM

    June 07, 2014


    Donation to Jupiter Broadcasting

    Chris Fisher’s Jupiter Broadcasting pod/vodcasting started 8 years ago with the Linux Action Show: still their flagship show, and how I discovered them 3 years ago.  Shows like this give access to FOSS to those outside the LWN-reading crowd; community building can be a thankless task, and as a small shop Chris has had ups and downs along the way.  After listening to them for a few years, I feel a weird bond with this bunch of people I’ve never met.

    I regularly listen to Techsnap for security news, Scibyte for science with my daughter, and Unfilter to get an insight into the NSA and what the US looks like from the inside.  I bugged Chris a while back to accept bitcoin donations, and when they did I subscribed to Unfilter for a year at 2 BTC.  To congratulate them on reaching the 100th Unfilter episode, I repeated that donation.

    They’ve started doing new and ambitious things, like Linux HOWTO, so I know they’ll put the funds to good use!

    June 07, 2014 11:45 PM

    June 02, 2014


    New features in socket_wrapper 1.1.0

    Maybe you already heard of the cwrap project. A set of tools to create a fully isolated network environment to test client/server components on a single host. socket_wrapper is a part of cwrap and I released version 1.1.0 today. In this release I worked together with Michael Adam and we implemented some nice new features like support for IP_PKTINFO for binding on UDP sockets, bindresvport() and more socket options via getsockopt(). This was mostly needed to be able to create a test environment for MIT Kerberos.

    The upcoming features for the next version are support for passing file description between processes using a unix domain socket and sendmsg()/recvmsg() (SCM_RIGHTS). We would also like to make socket_wrapper thread-safe.

    flattr this!

    June 02, 2014 02:36 PM

    May 27, 2014


    Effects of packet/data sizes on various networks

    I was thinking about peer-to-peer networking (in the context of Pettycoin, of course) and I wondered if sending ~1420 bytes of data is really any slower than sending 1 byte on real networks.  Similarly, is it worth going to extremes to avoid crossing over into two TCP packets?

    So I wrote a simple Linux TCP ping pong client and server: the client connects to the server then loops: reads until it gets a ’1′ byte, then it responds with a single byte ack.  The server sends data ending in a 1 byte, then reads the response byte, printing out how long it took.  First 1 byte of data, then 101 bytes, all the way to 9901 bytes.  It does this 20 times, then closes the socket.

    Here are the results on various networks (or download the source and result files for your own analysis):

    On Our Gigabit Lan

    Interestingly, we do win for tiny packets, but there’s no real penalty once we’re over a packet (until we get to three packets worth):

    Over the Gigabit Lan

    Over the Gigabit Lan


    Over Gigabit LAN (closeup)

    On Our Wireless Lan

    Here we do see a significant decline as we enter the second packet, though extra bytes in the first packet aren’t completely free:

    Wireless LAN (all results)

    Wireless LAN (all results)

    Wireless LAN (closeup)

    Wireless LAN (closeup)

    Via ADSL2 Over The Internet (Same Country)

    Ignoring the occasional congestion from other uses of my home net connection, we see a big jump after the first packet, then another as we go from 3 to 4 packets:

    ADSL over internet in same country

    ADSL over internet in same country

    ADSL over internet in same country (closeup)

    ADSL over internet in same country (closeup)

    Via ADSL2 Over The Internet (Australia <-> USA)

    Here, packet size is completely lost in the noise; the carrier pidgins don’t even notice the extra weight:

    Wifi + ADSL2 from Adelaide to US

    Wifi + ADSL2 from Adelaide to US

    Wifi + ADSL2 from Adelaide to US (closeup)

    Wifi + ADSL2 from Adelaide to US (closeup)

    Via 3G Cellular Network (HSPA)

    I initially did this with Wifi tethering, but the results were weird enough that Joel wrote a little Java wrapper so I could run the test natively on the phone.  It didn’t change the resulting pattern much, but I don’t know if this regularity of delay is a 3G or an Android thing.  Here every packet costs, but you don’t win a prize for having a short packet:

    3G network

    3G network

    3G network (closeup)

    3G network (closeup)

    Via 2G Network (EDGE)

    This one actually gives you a penalty for short packets!  800 bytes to 2100 bytes is the sweet-spot:

    2G (EDGE) network

    2G (EDGE) network

    2G (EDGE) network (closeup)

    2G (EDGE) network (closeup)


    So if you’re going to send one byte, what’s the penalty for sending more?  Eyeballing the minimum times from the graphs above:

    Wired LAN Wireless ADSL 3G 2G
    Penalty for filling packet 30%  15%  5%  0%  0%*
    Penalty for second packet 30%  40%  15%  20%  0%
    Penalty for fourth packet 60%  80%  25%  40%  25%

    * Average for EDGE actually improves by about 35% if you fill packet

    May 27, 2014 10:19 AM

    May 18, 2014


    Elasto Cloud Storage Gateway

    At this years SambaXP conference, I was lucky enough to be able to present the Elasto cloud storage gateway. Elasto is an open-source cloud storage library and client that I created as part of SUSE Hack Week.

    In addition to Elasto, the project makes use of istgt and existing operating system components to expose a cloud storage object as a local filesystem, on which all data is transparently encrypted before going anywhere near the internet.

    Such a tool can offer a number of benefits over traditional cloud storage clients:
    • Secure: Client-side encryption, via dm-crypt or Bitlocker, reduces reliance on transport and cloud provider security.
    • Cost effective: Client-side compression (e.g. with Btrfs or NTFS) improves cloud storage utilization.
    • Flexible: Standard interface, no vendor lock-in.
    Both Elasto and istgt components are available to download for openSUSE and Fedora. Given the immaturity of the project, be warned that its use may result in data loss or corruption - play safe, take backups!

    May 18, 2014 01:02 AM

    May 08, 2014


    BTC->BPAY gateway (for Australians)

    I tested out, which lets you pay any BPAY bill (see explanation from reddit).  Since I’d never heard of the developer, I wasn’t going to send anything large through it, but it worked flawlessly.  At least the exposure is limited to the time between sending the BTC and seeing the BPAY receipt.  Exchange rate was fair, and it was a simple process.

    Now I need to convince my wife we should buy some BTC for paying bills…

    May 08, 2014 02:55 AM

    May 05, 2014


    Testing your full software stack with cwrap

    Together with Jakub Hrozek I wrote an article about cwrap which is a set of tools to test your full software stack on a single machine. The article is open to the public now.

    Read the article …

    flattr this!

    May 05, 2014 07:23 AM

    April 14, 2014


    Group support for cmocka

    Last Friday I’ve released cmocka 0.4.0. It has several bugfixes and at least two new features. One is support for groups. This means you can define a setup and teardown function for a group of unit tests. I think some people have been waiting for this.

    You can find an example here. It is simple and easy to use.
    The other small feature is a new macro: assert_return_code(). It is designed for standard C function return values which return 0 for success and less than 0 to indicate an error with errno set. It will produce a nice error message! The rest are bugfixes and improvements for error message.

    Thanks to all contributor and bug reporter!

    If you think cmocka is a great piece of software, please vote it up on stackoverflow, thanks.

    flattr this!

    April 14, 2014 04:24 PM

    March 24, 2014


    Legal Questions About and Australia

    As my previous post documented, I’ve experimented with  Following the arrest of two Miami men for trading on localbitcoins, I decided to seek legal advice on the sitation in Australia.

    Online research led me to Nick Karagiannis of Kelly and Co, who was already familiar with Bitcoin: I guess it’s a rare opportunity for excitement in financial regulatory circles!  This set me back several thousand dollars (in fiat, unfortunately), but the result was reassuring.

    They’ve released an excellent summary of the situation, derived from their research.  I hope that helps other bitcoin users in Australia, and I’ll post more in future should the legal situation change.

    March 24, 2014 04:01 AM

    March 19, 2014


    Bitcoin Trading In Australia

    I bought 10 BTC to play with back in 2011, and have been slowly spending them to support bitcoin adoption.  One thing which I couldn’t get reliable information on was how to buy and sell bitcoin within Australia, so over the last few months I decided to sell a few via different methods and report the results here (this also helps my budget, since I’m headed off on paternity leave imminently!).

    All options listed here use two-factor authentication, otherwise I wouldn’t trust them with more than cents.  And obviously you shouldn’t leave your bitcoins in an exchange for any longer than necessary, since most exchanges over time have gone bankrupt.

    Option 1: MtGox AUD

    Yes, I transferred some BTC into MtGox and sold them.  This gave the best price, but after over two months of waiting the bank transfer to get my money hadn’t been completed.  So I gave up, bought back into bitcoins (fewer, since the price had jumped) and thus discovered that MtGox was issuing invalid BTC transactions so I couldn’t even get those out.  Then they halted transactions altogether blaming TX malleability.  Then they went bankrupt.  Then they leaked my personal data just for good measure.  The only way their failure could be more complete is if my MtGox Yubikey catches on fire and burns my home to the ground.

    Volume: Great (5M AUD/month)
    Price Premium: $25 – $50 / BTC
    Charge: 0.65%
    Hassle: Infinite
    Summary: 0/10

    Option 2:

    According to, localbitcoins is the largest volume method for AUD exchange.  It’s not an exchange, so much as a matching and escrow service, though there are a number of professional traders active on the site.  The bulk of AUD trades are online, though I sold face to face (and I’ll be blogging about the range of people I met doing that). is a great place for online BTC buyers, since they have been around for quite a while and have an excellent reputation with no previous security issues, and they hold bitcoins in escrow as soon as you hit “buy”.  It’s a bit more work than an exchange, since you have to choose the counter-party yourself.

    For online sellers, transfers from stolen bank accounts is a real issue.  Electronic Funds Transfer (aka “Pay Anyone”) is reversible, so when the real bank account owner realizes their money is missing, the bank tends to freeze the receiving (ie. BTC seller’s) bank account to make sure they can’t remove the disputed funds.  This process can take weeks or months, and banks’ anti-fraud departments generally treat bitcoin sellers who get defrauded with hostility (ANZ is reported to be the exception here).  A less common scam is fraudsters impersonating the Australian Tax Office and telling the victim to EFT to the localbitcoins seller.

    Mitigations for sellers include any combination of:

    1. Only accepting old-fashioned cash deposits via a branch (though I’m aware of one US report where a fraudster convinced the teller to reverse the deposit, I haven’t heard of that in Australia)
    2. Insisting on “” in the transfer message (to avoid the ATO fraud problem)
    3. Only dealing with buyers with significant reputation (100+ trades with over 150 BTC is the Gold Standard)
    4. Insisting on real ID checking (eg. Skype chat of buyer with drivers’ license)
    5. Only dealing with buyers whose accounts are older than two weeks (most fraudsters are in and out before then, though their reputation can be very good until they get caught)
    6. Only allowing internal transfers between the same bank (eg. Commonwealth), relying on the bank’s use of two factor authentication to reduce fraud.

    Many buyers on are newcomers, so anticipate honest mistakes for the most part.  The golden rule always applies: if someone is offering an unrealistic price, it’s because they’re trying to cheat you.

    Volume: Good (1M AUD/month)
    Price Premium: $5 – $20 / BTC
    Charge: 1% (selling), 0% (buying)
    Hassle: Medium
    Summary: 7/10

    Option 3:

    You’ll need to get your bank account checked to use this fairly low-volume exchange, but it’s reasonably painless.  Their issues are their lack of exposure (I found out about them through and lack of volume (about a quarter of the volume), but they also trade litecoin if you’re into that.  You can leave standing orders, or just manually place one which is going to be matched instantly.

    They seem like a small operation, based in Sydney, but my interactions with them have been friendly and fast.

    Volume: Low (300k AUD/month)
    Price Premium: $0 / BTC
    Charge: 1%
    Hassle: Low
    Summary: 7/10

    Option 4:

    I heard about this site from a well-circulated blog post on Commonwealth Bank closing their bank account last year.  I didn’t originally consider them since they don’t promote themselves as an exchange, but you can use their filler to sell them bitcoins at a spot rate.  It’s limited to $4000 per day according to their FAQ.

    They have an online ID check, using the usual sources which didn’t quite work for me due to out-of-date electoral information, but they cleared that manually within a day.  They deposit 1c into your bank account to verify it, but that hasn’t worked for me, so I’ve no way to withdraw my money and they haven’t responded to my query 5 days ago leaving me feeling nervous.  A search of reddit points to common delays, and founder’s links to the hacked-and-failed Bitcoinica give me a distinct “magical gathering” feel. [Edit: they apparently tried and failed four times to transfer the 1c verification to my ING account; with 1-2 business day support response, this took quite a while.  They never explained why this was failing.  Using my wife's CBA account worked however, and I got my funds the next day.  Upgraded their score from 4/10 to 5/10.]

    Volume: Unknown (self-reports indicate ~250k/month?)
    Price Premium: $0 / BTC
    Charge: 1.1% (selling) 2% (buying)
    Hassle: Medium
    Summary: 5/10

    If you trade, I’d love to hear corrections, comments etc. or email me on

    March 19, 2014 02:57 AM

    February 25, 2014


    The Gold Linker

    After the Update to Fedora 20 I forgot to update the linker to Gold. Today I released that linking Samba is horribly slow. Time to change the linker to Gold again:


    ll /etc/alternatives/ld
    /usr/sbin/alternatives --set ld /usr/bin/


    ll /etc/alternatives/ld
    /usr/bin/update-alternatives --set ld /usr/bin/

    flattr this!

    February 25, 2014 03:25 PM

    February 13, 2014


    SMBTA downloads available through it’s GitHub site

    Since our download server got down without further notice, we are working on moving the official download place under the realm. Meanwhile, SMBTA sources are available through it’s GitHub project releases page. Updated the Download Page.


    February 13, 2014 12:12 PM

    February 05, 2014


    Pettycoin and working with limited visibility.

    At I gave a last-minute talk previewing my work on pettycoin (video, slides), an experiment to shard a bitcoin-like network.  The idea is to trade off some security and robustness in return for scale, but use it only for small amounts where fraud is less worthwhile.  On the bitcoin network today this is already seen with zero-confirmation transactions, and this is the niche pettycoin seeks to fill.

    There are numerous problems to be overcome (one being the time taken by my day job, of course).  But segmenting the network and the blockchain is an interesting challenge: bitcoin’s blockchain is already designed so that you can have partial knowledge (mainly so you can prune used outputs).  But there’s a clear divide between full nodes, and second-class partial nodes.  I want a system where no one need know everything, and I’m getting closer to that goal.

    Consider the simplest useful transaction in the bitcoin network, with one input (ie. a previous transaction’s output) and one output.  To verify this is a fairly simple process:

    1. Is the transaction well-formed?
    2. Find the transaction whose output this is spending.
    3. Does the signature match the address of that output?
    4. Has that output already been spent?

    With bitcoin, you’re expected to know every transaction with unspent outputs, so if you can’t find the transaction at step 2, the verification fails. Even better, you can verify that previous transaction, too, all the way back to the creating of the coins involved.  Your only worry is that the blockchain you have is the same as everyone else’s, so they’ll accept your transaction later.

    If you don’t expect to know everything, it’s more difficult.  You can use a merkle proof to show that a transaction was present in a block; it takes just log(N) hashes for an N-transaction block.  So you could prove that all those previous transactions are in the blockchain (though that might be thousands of transactions) by providing me with each transaction and proof.

    But this can’t prove that there are not duplicate transactions in the blockchain itself.  Only knowing the entire contents would do that.  So we’re relying on the rest of the network, each with a partial view, to check that didn’t happen.

    This leads to the two requirements for any aspect of the pettycoin system which a node can’t verify by itself:

    1. The information to verify must be seen by some honest nodes.
    2. Each node must have an efficient way of reporting if it sees a problem.

    The former is a bit tricky.  Consensus is formed by the blockchain, but you don’t want to see all of it.  You might expect to see some fraction of it, but if you don’t, how would you alert the network in a way that can’t be faked?   Imagine a miner holds back 5 transactions in the block, the miner might wait for your complaint message on one, then release that transaction making you look like the dishonest one.  By making you cry wolf, they can ensure you are ignored.

    The solution used in pettycoin is that miners have to prove that they know the transactions in the 10 previous blocks.  They do this by hashing the transactions from the previous block into a merkle tree like normal, only they prefix each transaction with their payout address (this is called prev_merkle in the code).  The only way to generate this hash is to know the contents of each transaction, and you can’t make a valid block without it.  Unfortunately, the only way to demonstrate that this hash is wrong (thus the block is invalid) is to also know the contents of each transaction in the block.  Thus transactions are batched into groups of 4096; you only need send 4096 transactions to prove that one of the hashes in a block is wrong.  Miners will insist on knowing the transactions for those blocks, knowing that if they fake it they’ll likely be caught.

    Reporting most other problems in a block is fairly:

    1. You can prove a duplicate spend in the block chain by showing both transactions and the merkle proofs that they are in each block.  The second block is invalid.
    2. You can prove a malformed transaction by showing the transactions and the merkle proof it is in the block.  That block is invalid.
    3. You can prove an overspend by showing the transactions used as inputs.  That block is invalid.

    But if a transaction in a block relies on an output of a transaction which never existed, you can’t prove it.  Even if you know every transaction which ever happened, you can’t prove that to me (without sending me the whole blockchain).  The initial design lived with such warts in the blockchain, instead insisting that you would have to show all the predecessors when you paid me (via a payment protocol).  That predecessor tree quickly becomes unwieldy, however.

    The new approach is that for each input of a transaction in the blockchain, the miner has to include the block and transaction number where it appeared.  Now anyone who knows that previous transaction can check it, and if there’s a problem it’s easy for any node to prove by showing the transaction which is in that previous block (with merkle proof that it is).

    This means that the blockchain can be trusted, if half the mining power can be trusted.  This is a weaker guarantee that bitcoin, but sufficiently strong for pettycoin.  If you send me a new transaction along with transactions it uses as inputs  and merkle proofs that they are in the blockchain, I only need ensure that the new transaction isn’t a double-spend.  That’s the same as the bitcoin network, with zero-confirmation transactions (though pettycoin has a special double-spend report message to expedite it a little).

    Next post, I’ll respond to the best criticism of pettycoin yet, the problem of gateways (by Jason Gi)…

    February 05, 2014 07:49 AM

    Last updated: August 02, 2014 04:00 AM


    Nowadays, the Samba Team needs a dollar instead of pizza ;-)

    Beyond Samba