Generally speaking, you can store any kind of files in a git repository.
Git was not designed for storing database data in the form of tables, rows and columns. You can still treat that kind of information as binary data and store it in the device, but it will not have database functionality.
There is no hard coded limit for the file size. Managing repositories with sizes of 100 MB or more are no problem for the device. Typical images with a size of 10 MB in repositories performed well.
Previewing images in the user interface works well for typical image sizes. Previewing or editing large code files in the web browser may cause performance issues with some browsers. In such cases it is recommended to edit those files locally with a standard code editor.
You can also store very large files such as videos. The files are not kept in memory, but will have to pass through the various processing steps which can take some time to complete. File sizes of several hundred MB should still be practical.
The device generally stores anything that is in a git repository. Typically coders are using this kind of repository, including programmers, web designers but also professionals like hardware designers. Depending on their ability to use the command line, other professionals like architects, or biotech researchers can use the device as well.
It is worth training employees the basic usage of git clients. Storing files in revisions is a generally useful skill for anybody working on digital data.
We encourage users to try the native git client from the command line, as it provides the full feature set and ultimately increases the productivity of the users. There are several git clients available for Windows, MacOS, Linux, FreeBSD and other operating systems. There is a list of git clients at the git website. Depending on the user profile and skills, those clients can be command-line based or graphical. Some tools even have a built-in git client. We expect that more and more tools add git support.
Yes. For simple operations, you can also edit files right from the web interface of gitstorage. This has the advantage that the file is not stored on your client and you don’t have to install any software, not even the git client. However, the editor there provides you only with basic editing features.
If you want to run your gitstorage device behind your firewall and access it from outside, you will have to forward ports on the router. This makes sense, e.g., if you run gitstorage in your office and want to access it from home. You will need to forward port 443 to your gitstorage device to get this done. In order to reduce public exposure, we recommend using a non-standard port so that scanners don’t constantly access the device.
It's generally desirable to assign a static IP address that does not change across reboot cycles. There are several ways this can be achieved: Tell your DHCP server what address to assign to the device. Most DHCP servers can do this today. This also makes sure that you don’t get an IP address conflict.
Use the link-local IPv6 address of the device. gitstorage supports IPv6, which comes with an IP address that essentially uses the Ethernet address of the device, which never changes.
As a last resort, you can still enable SSH access to the device and assign the IP address from the Linux shell using the standard Linux way to do this.
Yes. If you have access to your DNS, we recommend that you assign a static IP address to the device on your DHCP server and set up a DNS record. If your router supports “hair pinning” and you have set up port forwarding, you can also set up the public IP address as the DNS address, so that you can use the same DNS address inside and outside your LAN.
Yes and no. The web front end does not provide you with any help setting this up. However, if you enable SSH, you can log in and do this on your own in Linux. Depending on how many people need this, we might add this to the web front end some day and ship it with a software update.
This is something we might look into in later versions, as it helps running a critical service in the network. This would currently fall into the feedback category.
Yes and no. In the end, the device is a Linux computer that can do many things, like servicing files or managing network addresses. However, it defeats the purpose of the standalone device to run additional services that will ultimately break the security model for the device. Although we won’t stop you, we strongly discourage you from running additional services on the device.
You can use standard USB power supplies. In some countries that have non-mainstream power outlets (from a global perspective) it might make sense to use your own power supply. You might want to make sure that the power is not accidentally plugged out, as this requires re-entry of the file system password. In counties with frequent power outages, it also makes sense to have the power supply on a UPS (Uninterruptible Power Supply).
Not necessarily. But we recommend that you install the device properly in a suitable location. If you have a server closet with a wood panel, this would be a great location to install the device using the screws that we supplied. Using the screws makes it harder to take the device. If possible, you should also fix the cable to the power supply to make sure that it does not get removed easily. The environment should not be wet, have a high humidity, be very hot or very cold. You can for example also install the device right under your table, as this is usually a location with moderate climate. Because the device is rather small and does not generate any noise, it will not bother you when working.
No. You own the device and may run the device as long as you wish. For software updates, you will have to pay an extra fee of 99 USD, but there is no obligation to do that. The first year you can update the gitstorage software without extra charges.
It would be unrealistic to promise free software updates for the lifetime of the product. For the first year we provide software updates for free, but after that, there needs to be a realistic business model that makes it possible to pay people for product improvements. Compared to other products and services in the space, we believe the fee is still quite reasonable and because there is no obligation has only benefits for the customer.
Yes and no. We intend to make the product easy to use and to minimize the need for support. We try to provide online documentation that covers as many topics as possible so that there is no need for time costly one-on-one support. What we don’t want to do is babysit customers on how to use git in general; there is plenty of information out in the Internet for that, and we don’t even consider ourselves as git gurus. We do encourage customers to provide feedback for the device, suggest features that make it more useful.
We encourage that you share your experience with the device on the public forums and places for product comments. You may also share your experience in a private conversation. We would love to hear how the device is used and what we can do to make it suitable for more environments.
No. We did not put any backdoors into the software. If you lose your passwords for the device and the backup, you’ll lose access to your data. This will be final. This is why you should store your password in a safe location. If you have a copy of the repository on a client, you should be able to restore at least most of the relevant information.
For the admin login, the encryption of the memory card and for the backup encryption, you should choose really good passwords. The password quality checker in the web interface is trying to help you avoiding passwords that are already known (dictionary attack), the checker is not there to make your life harder.
You can change the password for the admin login later. It is a good practice to change passwords from time to time.
Changing the password for the encrypting of the file system is not possible later, so you have to be really careful about this one. Only a factory reset can reset that password, but you’ll lose all data that has not been backed up before.
Changing the password for the backup encryption will have an impact only on new updates; older backups need to use the old passwords.
We encourage customers to choose a truly random password algorithm like closing the eyes and punching keys on the keyboard, so that nobody can guess the passwords. We suggest that if you have a safe or another safe location, write those passwords on paper, put them into a sealed envelope, name the envelope and put them in the safe. Or instead of writing the password in clear text, write a hint on how to retrieve the password on paper. Do not rely on your browser to store your information.
You have to keep in mind that in a company environment, staff might be changing. It is important that you prepare for this when you set up the passwords. If you are the owner of a company, it is useful that you have a copy of the root, file system and backup passwords even if you are not personally involved in maintaining the device. The same applies to managers, who should be able to pass the information on to the next manager.
You should also prepare for the event of a power failure. You need to make sure that the administrator has the root and file system password ready in that event. This might be a problem if your power is very stable. The device might run for years without the need to enter the password again. Make sure that you know where the passwords were stored.
There are two cases to keep in mind. If a team member leaves, you can delete the user on gitstorage or just change the password if you are not sure yet if you want to delete the user. This will make sure that that member can no longer access the repository.
If your gitstorage administrator leaves, you have to ask the person to log in one more time and then enter a new root password. If the administrator remembers the file system encryption password, it will be useless without the new root password. You should also change the password for the cloud backup and make sure that you have the password for the previous backups.
The system typically looks like this for the GS-64 model:
root@gitstorage:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 185184 0 185184 0% /dev tmpfs 50684 5628 45056 12% /run /dev/mmcblk0p1 61462796 2589572 58249144 5% / tmpfs 253412 0 253412 0% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 253412 0 253412 0% /sys/fs/cgroup tmpfs 253412 4 253408 1% /tmp /usr/local/gitstorage 61462796 2589572 58249144 5% /usr/local/gitstorage tmpfs 50684 0 50684 0% /run/user/0
/dev/mmcblk0p1 is the device for the SD card. The actual size might vary depending on how many good/bad blocks are available on the device.
git repositories store the URL to the server in a file called
.git/config. It contains a tag called
remote that you can edit with a text editor. The URL for the repository is shown when you push the clone button in the web interface for your repository.
[remote "origin"] url = https://gs.mycompany.com:43452/repo/prjfalcon fetch = +refs/heads/*:refs/remotes/origin/*
Most git clients use this field when pulling or pushing data to the remote server. Typically there is no need to change that git client or clone the repository again.
There are many ways to get this done. An easy way is to save the root CA for the device somewhere and configure git to use it. The root CA can be copy & pasted from within the gitstorage web interface:
user@git-client:~/repos$ cat >~/.gitstorage.cert <<END -----BEGIN CERTIFICATE----- MIIDpTCCAo2gAwIBAgIJAKrxO5Z5RwR3MA0GCSqGSIb3DQEDCwUAMGkxCtAJBgNV ... vfM/LlEvdqp65+OKoV55aCtf/zW2tARLBA== -----END CERTIFICATE----- END user@git-client:~/repos$ git config --global http.sslCAInfo ~/.gitstorage.cert user@git-client:~/repos$ git config --global credential.helper 'cache --timeout=36000'
The last command instructs git to use the password cache, so that you don't have to enter the credentials over and over again. The timeout for the passwords is set to 10 hours in this example.