I have a samba server with ldap to manage users in my office. I have been reading articles about creating a samba server and I have founded out something about users limit: "the Samba Team does not recommend using the tdbsam backend for sites that have 250 or more users.", many articles say the same about this limit, but this articles are old, some of them about 10 years old.
My question is: Is Tdbsam backend still recommend using at least 250 users? Is there another limit recomendation?
Thank you.
Found an answer to this exact question on page 85 of John H. Terpstra's guide Samba-3 by Example:
The tdb data structure and support system can handle more entries than the number of accounts that are possible on most UNIX systems. There is a practical limit that would come into play long before a performance boundary would be anticipated. [...]
As the network grows, it becomes necessary to provide additional authentication servers (domain controllers). The tdbsam is limited to a single machine and cannot be reliably replicated. This means that practical limits on network design dictate the point at which a distributed passdb backend is required; at this time, there is no real alternative other than ldapsam (LDAP).
The guideline provided in TOSHARG, Chapter 10, Section 10.1.2, is to limit the number of accounts in the tdbsam backend to 250. This is the point at which most networks tend to want backup domain controllers (BDCs). Samba-3 does not provide a mechanism for replicating tdbsam data so it can be used by a BDC. The limitation of 250 users per tdbsam is predicated only on the need for replication not on the limits of the tdbsam backend itself.
(emphasis mine)
Related
I'm using Ruby on Rails 4.2 with mySql for my HIPAA Compliance application and I need to know the technical database requirements for this application.
do we really need to encrypt all the database values such as patient name etc?
Yes You have to encrypt all the details(name, email, phone, address) related to patient and doctors if you want your Rails application to be HIPAA Compliance.
Here below 2 Ruby gems are very helpful for you.
attr_encrypted: https://github.com/shuber/attr_encrypted
paper_trail: https://github.com/airblade/paper_trail
HIPAA is an unusual law in that it makes a lot of recommendations (addressable items) and a few assertions (required items), but in the end it is up to each organization to determine for themselves what they need to do to be compliant.This creates a great deal of flexibility and also a great deal of uncertainty. In general, to be HIPAA-compliant, a web site must at a minimum ensure that all protected health information (ePHI) below:
Transport Encryption: Is always encrypted as it is transmitted over the Internet
Backup: Is never lost, i.e. should be backed up and can be recovered
Authorization: Is only accessible by authorized personnel using unique, audited access controls
Integrity: Is not tampered with or altered
Storage Encryption: Should be encrypted when it is being stored or archived
Disposal: Can be permanently disposed of when no longer needed
Omnibus/HITECH: Is located on the web servers of a company with whom you have a HIPAA Business Associate Agreement (or it is hosted in house and those servers are properly secured per the HIPAA security rule requirements).
The HIPAA requirements not nearly strong enough. In short it states that you must encrypt medical records at rest and you cannot use a broken primitive, which is obvious. Whoever audits your system probably like to see AES. This is trivial to support, and an Amazon RDS MySQL instance already supports this out of the box with the aes_encrypt() and aes_decrypt() functions.
Where HIPAA and PCI-DSS fall short is that they don't state what mode of operation should be used. In fact MySQL's aes_encrypt() uses ECB mode, which is horrific. Further more, there are problems with enforcing security when using encryption at this layer. aes_encrypt() is easy to break by configuring mysql to log all queries. The AES key must be embedded in your application so if it is compromised, the attacker could read the value out of a configuration file and access the records. This is two points of failure that can be avoided by encrypting the data within your application and then transmitting cipher text to the database. But HIPAA doesn't care about this problem. HIPAA's other requirements, such as requiring a CISSP to analyze your application is more important.
I urge you to implement a secure system, but HIPAA wasn't designed well enough to care.
I have a .mdb MS Access 2007 which is connected to a SQL Server backend. The tables are linked using a system DSN.
I need to do a stress test on the system and I would like to know the maximum number of users who can use the system at the same time.
The access .mdb file is done through the WTS.
Thanks for the help
The max number of users is going to depend on how well the application is written, and how good the network each user has.
You might have a great application, but if they are connecting to SQL server over a slow network, then the application will be slow with 2 users, and will be slow with 250 users.
If the network is good, and the application is well written to respect bandwidth requirements, then the application will likely run the SAME speed with 2, 10, 20 or 100 users.
And deepening on how large and powerful the SQL server box is? Then you can easy scale out to 500 users at the same time.
So this question is much difficult to answer. The network from the Access application to the SQL server is an important factor.
And some applications perform poorly with 5 users and SQL server, and thus such applications will perform even WORSE with 100, or 200 users.
So how well does the application work with 5 users, and then with say 25. If it written well, you likely not notice the difference. On the other hand if it slow with 1 user, then you downhill all the way from that point on as you add more users.
So it better run REALLY well with one user if you planning to scale out to many users.
So it certainly possible to have a 1000 users at the same time without much effort. As noted this depends on how well the application was designed with SQL in mind. So the quality of the work the developers done will be the LARGEST factor in how many users you can scale out to. As noted the capacity of the server and SQL will also determine the max number of users.
With a typical application that respects SQL server, then running 50 or 100 users should hardly break SQL server into a sweat is should be easy obtainable.
In fact for those 50 users, your HUGE resource HOG will be WTS.
Assuming you mean windows terminal services, then that setup requires HUGE resources, and far more then your SQL server will. This system will require much more attention and resources then SQL server. As noted, if the application runs rather well with 1-2 users, then usually such applications will run easy with 25. If the application runs slow with only 1 or 2 users, then you going to have scaling problems as you add more users.
At the end of the day, there are FAR FAR too many factors to give an answer without a case by case knowledge of the server involved, the network bandwidth, the capacity of the WTS, and MOST important how well the application was designed (this factor is #1).
I am developing an Android application for my college. There will be no more than 10000 users in total, and we can assume that no more than 500 concurrent users will be there at any given time.
They all will be posting their status, photos, making comments (except video sharing). I am using only MySQL as database (without memcache or some other technology) and PHP as web service.
I want to ask, will a shared server serve for my purpose? Because it will be a free app and the cost of dedicated server will be too high.
It's difficult to give specific answer.
Hosting companies very often offer possibility to test their hosting for some time (e.g. 14 days). I think you should use this free period and do performance tests. Then you will know wheter it's enough for your neeeds.
I have looked everywhere...
whats the difference between a hosted database and a cloud database they seem like the same things?
Thanks
Both "hosted database" and "cloud database" mean that the database lives on the servers of some external provider/hoster.
The hoster might even be the same in both cases.
The main difference is that the "cloud" plans are usually meant to scale more (at a higher monthly fee), so you'd use them when you expect your site to get huge soon and need to quickly adjust server capacity when needed.
On the other hand, "hosted" plans are not that expensive, but have more limitations (server speed, database size...) and are more suited for "small" websites.
Of course this isn't by any means an "official" description of the two terms, but that's the impression that I get every time I see "cloud" or "hosted" webspaces/databases/services/whatever.
It depends on the context in which they're being used, but, yes, they usually mean the same thing. When I see the term cloud database being used they are usually referencing some cloud platform like Amazon EC2 or Microsoft Azure instead of GoDaddy or HostGator or something. Plus, cloud is the new buzz word - I'm sure it sells better. Lol.
As Christian Specht said, the cloud servers really scale more. So why you need more scaling? and why there are many featured options in cloud database service selection?
Things are not like before. Before smartphones and earlier pc operating systems, users gets information from the server only when they log on the specific web page using their credentials. But now apps like facebook shows notifications, provide ads etc and collect/push other data in parallel while we are looking at something else irrelevant.
Hosted database are reliable to access the database when users log onto the web page. But in case of the lastest smart phone applications, it needs to access the database everytime starting from its birth (installation on the device). So for each installation, the minimum workload over the server is expected to raise up.
So more scalability is required here. More simultaneous connections, Input/Output operation requests are expected daily. So with the dedicated servers with the core purpose, and with the configurable package selection based on your expectation of user count and bandwidth usage, Cloud Service is not yet another marketing term, but is a helpful service.
INFORMIX-SQL 7.32 (SE) Linux Pawnshop App.
I have some users who own several pawnshops within a 100-mile radius. Each pawnshop app runs with SE. The only functionality these owners need are: ability to remotely login to any store in order to view transactions, running totals and consolidate daily totals at end of business day. This can be accomplished with dialup modems, as the app doesnt have any need for displaying BLOB's. At end-of-day, each stores totals are unloaded to a flat file and transferred to the owner's system.
What would my owners gain by converting to distributed db's?.. ability to find out if a stores customer has conducted business in another store or if another store has a desired inventory item for sale? (not important, seldomly happens). Most customers will usually do business with the same store and if they dont have a desired item for sale, they will visit the closest competitors pawnshop. What gains would distributed db's offer to accomplish the same functionality as described in the first paragraph?.. Pawnshop owners absolutely refuse to connect their production systems via the internet! They dont trust its security, even using VPN, Cisco, etc, or its reliability! In this part of the world, ISP's have a bad track record for uptime. I know of several apps which have converted from web to dialup because of comm problems!
Distributed DBs, more precisely Informix XPS and IDS, don't have just one advantage. If you care just about getting data from different places, you can accomplish it with just a design strategy. If you add a "branch_id", or something like that, you're done.
Distributed DBs have a lot of advantages, from availability to scalability. You must review all these things first.
Sorry for this kind of answer, but is really difficult to give you an straight answer about this topic.
CouchDB is a peer based distributed database system. Any number of CouchDB hosts (servers and offline-clients) can have independent “replica copies” of the same database, where applications have full database interactivity (query, add, edit, delete). When back online or on a schedule, database changes are replicated bi-directionally.
CouchDB has built-in conflict detection and management and the replication process is incremental and fast, copying only documents and individual fields changed since the previous replication. Most applications require no special planning to take advantage of distributed updates and replication.
Unlike cumbersome attempts to bolt distributed features on top of the same legacy models and databases, it is the result of careful ground-up design, engineering and integration. The document, view, security and replication models, the special purpose query language, the efficient and robust disk layout are all carefully integrated for a reliable and efficient system.
If you are not going to have general 90%+ uptime connection between the databases, then there isn't any benefit to distributed databases.
One main benefit is to give large businesses a 'failover' when one machine goes down or is unavailable. If they have the database distributed over three or four machines, then the loss of one doesn't impact their ability to do business.
A second major benefit is when a database is simply too big for one server to cope with. 'Internet scale' databases (Amazon, Twitter, etc) have that level of traffic. Walmart would have that level of traffic. A couple of storefront operations wouldn't.
I think that this is a context where there is little to gain from distributed database operation.
If you were to go towards distributed operation, I'd probably look towards using a simple ER topology, with the 'head office' store being the primary (root) node and the other shops being leaf nodes. You would then have changes to the individual store databases replicated to the HQ node; you might or might not also propagate the data back to the other stores. Especially with just two stores, you might in fact simply replicate all the information to both stores; this gives you an automatic off-site backup of the database. (You'd probably configure all nodes as root nodes in this case - at least, until a chain grew to, say, five or six nodes.)
This would give you some resiliency for disaster recovery. It would also allow the HQ (in particular) to see what is going on at each store.
My impression is that you are probably not discussing 'transactions per second' on average; the rate of transactions at a single store is probably a few transactions per minute, with 'few' possibly being less than one TPM. Consequently, the network bandwidth is unlikely to be a bottleneck at any point, even with dial-up speeds (though that might be borderline).