Version Control Systems, lock files on read - file

I'm in a company which demands simultaneously collaboration on a web application, to avoid any conflict during development our CEO suggests the use of SVN version control system so each user can lock the file when they're working on it.
SVN does support locking files for each user but the problem is we need to lock the file on reading, SVN as I know to make you check for any updates every time you want to see the locking status on files. What we need is to not letting other users even open/read the files that have been locked! does SVN have such a feature?! or is there any other technologies like google drive to achieve such a mechanism?
Thank you all.

Related

How to follow a updating local file while using flink

As mentioned in the document:
For example a data pipeline might monitor a file system directory for new files and write their data into an event log. Another application might materialize an event stream to a database or incrementally build and refine a search index.
So, how can I follow a local file system file updating while using Flink?
Here, the document also mentioned that:
File system sources for streaming is still under development. In the future, the community will add support for common streaming use cases, i.e., partition and directory monitoring.
Does this mean I could use the API to do some special streaming? If you know how to use streaming file system source, please tell me. Thanks!

TeamCity: is it possible to to use Subversion SVN from a file:// share?

Is it possible to use SVN as source control for a project, but instead of connecting to svn://servername, I would like to connect to file://servername/SourceControl/SourceDb share. But apparently this is not supported?
Gives error message:
TeamCity is trying to protect you from yourself. While Subversion does (or at least used to) support repository databases placed on file shares, doing so is very dangerous:
A single keystroke (intentional or otherwise) by anyone with access to the repository will render history lost at best, and the repository useless at worst
Path-based authorization cannot be enforced
Hook scripts can easily be bypassed
Depending on how the share is hosted, various problems may crop up
From the Subversion manual:
Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems
Stand up a proper server.

Directories for Ossec FIM

I am new to Ossec, and have recently installed it on a server forthe company I am currently working for.
This server monitors 80 Windows 7 agent machines. The main purpose for setting up Ossec on these agent machines was so we could deploy file integrity monitoring.
Now to my question; What sort of directories should I be monitoring? So far I only have the default directories provided by default from Ossec. I have also added FIM to the 'System' and 'System32' directories. Are there any more directories or files you would recommend I monitor?
Kind regards,
Alex
In part, the answer depends on why you installed OSSEC. If you installed it to be compliant with a regulation (like GDPR) you probably need it to monitor any files that relate to policies. For example, if you have a policy that all passwords must be 10 characters long and you have a settings file that enforces the 10 characters you should monitor that file.
You should have OSSEC monitor any configuration files. You might also want it to monitor user files and data files.
Think about what you need to protect. If a bad actor were to get access to one of those computers what would they likely change? With the answer to that question you'll know what to protect.

Run application updates with non admin users

I'm using a windows installer package to distribute a winforms application to several clients and because some of them have changed their security policies I need to figure out a way to run the application updates (through the installer) for users without administration rights.
Find below some information regarding the update process:
- The installer is created using InstallAware
- During the update process the old version is uninstalled and the new version is installed.
- The installer needs admin rights because it writes to the registry and installs some windows services.
- The application is installed in the program files folder.
At this moment the solution that I'm implementing is create a new scheduler task, that runs a simple console application that check for new updates and if a new version exists it downloads the installer and executes it in silence mode (the entire installation will execute silently, without a user interface, or any user intervention. The default values of dialog controls will be used).
Some consideration about this solution:
- It's difficult to handle possible errors during the update process.
- It's not possible to alert the user that a update process is running (because the scheduler tasks runs with a different user is not possible interact with the logged user).
Has anyone ever implemented anything similar? Is this the best way to achieve my goal?
If the updates are patches, and you meet a certain set of requirements regarding the first install of the product and sign both the MSI and the patches there is a mechanism for limited users to apply patches, UAC Patching described here:
http://msdn.microsoft.com/en-us/library/aa372388(v=vs.85).aspx
If you search for LUA Patching (its original name) or Least-privilege patching there's more info out there, although it's fairly obscure. If the security policies that they have in place include setting DisableLUAPatching then you won't be able to use it.

SVN server Auto Synchronization with Local Database # Runtime

I am using ProjectLocker as my SVN server.Stuck at Files Synchronization at run time with Local DB Files. I am using Tortoise SVN.
From your comments, it sounds like you may not be familiar with some version control concepts. For new Subversion users, I recommend Chapter 1 of the Version Control With Subversion book. This will explain what a working copy is in more detail, and how Subversion keeps your data. Chapter 2 has more information on a basic work cycle. ProjectLocker takes care of all the svnadmin steps for you, so you can ignore those and look at how to check out, update, and commit.
The first thing you should do is to create a staging directory where you keep any files that you're doing development on. You may need to copy your PHP, CSS, DB files and so on to that location. You then run the TortoiseSVN equivalent for svn import to upload all the files to your server. Once you've imported them, back up the directory you just created, and create an empty working directory. Run the TortoiseSVN equivalent of Subversion checkout and you will pull down all the files in your repository. Once you have that, Subversion will take care of identifying which changes can be merged and which will need manual intervention as you make changes, run updates to pull changes from other users, and commit.
If you wish to upload files to a remote location after commits and you have a paid account, you can use ProjectLocker's remote deployment solution to FTP a particular Subversion directory over to your actual server for deployment.
I apologize if this is a little vague, but the scope of your question is quite broad, and so I wanted to give you as concise an answer as possible while still addressing your needs.

Resources