This may be a stupid question but after a fair bit of googling i and still unsure weather i should be removing the the composer.phar file after installation. Is the files just part of the installation or required to run the application ?
The Composer executable is used to manage your dependencies, which is mostly "update" and "install". The result is an autogenerated autoloader and a complete tree of files from the required packages of the application.
The executable itself is not part of the application and therefore is not needed to run it. For security reasons it should not be present on the live servers unless you really know it has to be there, because it seems like a good idea to not give an attacker some useful tools into their hands.
The proper places to have the executable are your development environment (in order to add new packages and update the old ones) and the deployment server that puts the application onto the live server (otherwise you cannot install the packages that your application runs with).
I know that people tend to create a workflow that simply pushes a branch to production, and a post-transmit hook then runs composer install, but this is dangerous from a reliability standpoint: What if Github has an unexpected downtime and you push to production, unable to download the new packages? In this scenario, the server doing the deployment actually is the production server and so requires a copy of the Composer executable, but I explained that this is no ideal setup.
Related
A little backstory:
I am creating my first Go web app for school. The professor said that I could use Go. I asked him if I could use the latest version, 1.13, rather than the version installed on the server, 1.10, to leverage the module management feature and the updated errors module. He did not say that I was restricted to 1.10 and even gave me the contact information of the server admin. I reached out to the server admin with my professor CC'd and he said he doesn't want to update the server's version of Go in the middle of the semester. He then included instructions on how to download, install, and use whatever version of Go that I need in my home directory.
Pick your version:
https://golang.org/dl/
Set it up for your own use:
https://golang.org/doc/install
I installed go 1.13 and updated my own envvars to reflect this version and everything works.
Well, the other requirement is that I have to hand my professor my project and that it has to compile on the server. I am thinking that if I hand him a bundle and give him directions on how to build it, then I've technically met the requirements of the project so far.
My question is, does Go have anything that takes my Go v1.13 environment and packages everything up so that the project can compile on the target server? I have only been able to find solutions along the lines of "just copy the project binary to your production server" but that doesn't help me. I need it to compile on the production server. Besides, I tried copying my binary to the production server and it couldn't find my html templates (stored in ./ui/html/ directory) but I guess that will be solved in this discussion or saved for another SO question later.
student#universityserver:~$ ./web
INFO 2019/09/22 10:21:52 Starting server on :5089
INFO 2019/09/22 10:23:03 <ipaddress>:63527 - HTTP/1.1 GET /
ERROR 2019/09/22 10:23:03 handlers.go:29: open ./ui/html/home.page.tmpl: no such file or directory
The only thing I can think of right now is to basically add everything they need (the go amd64 binary distribution and all modules) and write a script that handles it all (extract go in local folder, export envvars, build, etc.)
Dear, Professor.
Copy this tarball to your home directory, extract, run build_my_goapp.sh script.
Sincerely,
Your student
The answer in my case was that I can supply a Makefile that does anything I need it to do.
(It's actually good practice, if not an expectation, of a project that is turned in.)
The requirements were that my project needs to compile on the server and that I had to supply a Makefile. Therefore, any downloading, installing, and setting up of a Go environment for my project can be done, as long as everything happens in the user's environment and is not something that needs sudo to install correctly. The server does not have Docker.
Good evening,
This question is has to do with the PHP composer packet management. I have installed in on our test environment (xampp) without any issues and have downloaded the necessary package without any problems (package name: mpdf). After I issue the command to get the package, the vendor package showed up as it should have and my project worked great.
Fast forward, we are not ready to deploy this whole application to a linux(ubuntu 16.04) box using a versioning system (svn) and all the files that were on the test system have been deployed to production. The only problem is that the specific parts of our site on production that needs the mpdf package does not work.
My question is this, even though the vendor folder was also copies to production using SVN, is there anything else for us to do to make this work on the production box?
I am mainly speaking about any necessary steps that might need to performed on the ubuntu box?
Thank for all the help in advance,
George Eivaz
I figured out what the issue was. It had to do with the permissions not being correct on Ubuntu.
I am working on a Laravel project and it's working fine. But
Recently I have updated Composer by composer update and Composer updated successfully.
Then I have removed unnecessary packges from the vendor folder. I have also removed paragonie folder from vendor, which is unwanted for me.
This gave me following error.
Fatal error: require(): Failed opening required '/var/www/laravel/vendor/paragonie/random_compat/lib/random.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/laravel/vendor/composer/autoload_real.php on line 54`
I have added this folder and working fine.
Any one can help me to figure out what is purpose of paragonie folder.
Why it is included?
Composer manages every package inside the vendor/ folder. You simply can't remove any folder from vendor/ without breaking something. Don't do this!
If you want to remove packages from your project then edit your composer.json and perform a composer install.
There might be some packages in your vendor folder that are not required from your composer.json. This is because ever package can have it's own requirements. If you delete one of these required packages you break it.
There is generally NO necessity to remove anything from vendor!
Note: composer update does NOT update Composer itself. It updates every package of your project! To update Composer itself use composer self-update.
I really recommend you to read the composer docs or some tutorial on how composer works for a better understanding of composer.
Don't manually edit composer.json, or the file-structure of the vendors folder. The vendors folder contains the dependencies and their dependencies.
The most important part about this is that you should not EVER edit a project dependency within a project. The second you do, you have broken future updates, This is a terrible thing.
If you feel this is not possible because a library needs changes, I'd suggest taking a breath.
Most libraries have some built-in configuration options, or methods of modifying the library. If they don't then maybe contribute some, or fork the library.
You can absolutely make changes to any library that has a permissive license towards source code modifications, that is why open-source code exists, but you need to do this in the right way.
You can possibly improve the code by forking using source control, which will also allow you to submit a pull-request(PR) to the package maintainers.
The benefit of trying this is that IF the package maintainers decide to accept your changes, you will be up-to-date with all of their future updates, even if you do not have time to maintain your changes, someone will probably pick them up and make their changes.
IF your PR is not accepted; I would strongly consider revisiting your initial assumptions so that you can be sure the decisions you are making are the only way, or the most beneficial way forward. Either way; it won't matter, as you can keep your fork as the version you pull from in future and either add it to packagist (only if you are really more people will benefit from it); or telling composer to pull directly from your repository (it does have to be on the internet AFAIK).
If you have to fork, you will need to ensure you can maintain the dependency, and this is accepted within your organisation. If it's you then in future, you can manually update from time-to-time from the original source library; to ensure you still enjoy the benefits of the core library, whilst keeping your changes.
THIS IS THE DIFFERENCE BETWEEN HIGH-SCHOOL CODING AND PROFESSIONAL DEVELOPMENT.
sorry for shouting / exclaiming, but this needs to be put out there more, possibly in 100ft letters somewhere.
Resolving this problem folowing these steps:
go to your project from terminal (CLI)
cd vendor
svn add paragonie
svn commit -m ""
And if another file is missing do the same thing.
For me it works 100%.
Good luck.
I have a Laravel 4.2 application and it in production environment.
Sometime i have bug fixes or updates for it in the local edition, I want to know how do i move these changes from local to production.
Replacing just the file/class that was changed doesn't work. I tried replacing just the controller file but it doesn't work.
Does Laravel compile the code somewhere that i need to upload to production server, What all do i need to change/upload in production to reflect the changes?
By default, PHP is not a compiled language, so changed and uploaded files will work without any special process. Laravel is just PHP, so it follows the same rules.
However, Laravel uses an autoloader that keeps track of all of your classes. When you add a new class, you need to tell the autoloader that it exists by running:
composer dump-autoload
This will scan the available classes and update the autoloader list.
If the problem persists after you run composer dump-autoload, or if you did not add any new classes, there are three potential problems to consider:
Did you upload the files correctly?
Log onto the production server and look at the timestamp of the uploaded files. Do they match your expectation? Consider opening the files in production to see if they contain your latest changes.
Do you have a caching or compiling system in place?
While PHP is not compiled by default, there are tools available that allow you to compile it, and other tools that allow you to cache the output of the scripts. Ask your server administrator if any of these tools are being used.
Do your changes perform as expected?
Finally, check to see if your changes are in production, but not operating in the way that you expect.
We are currently using VSS for version control. Quite few of our developers are interested in a distributed model (And want to get rid of VSS). Our network is full of Windows machines and while our IT department has experience maintaining Linux machines they would prefer not to.
What DVCS systems can host their central repository on Windows while providing..
Push access to the repository.
Basic authentication. Mostly just a way to allow or deny access to the whole repository. No need for fine grained access.
Server process so users don't need write right to the repository reducing the risk of accidentally messing with it.
On the client side a GUI such as Tortoise would be more or less a requirement (Sorry, Windows shell sucks. :|). Ease of installation would be a huge plus as our IT department is already quite low on resources. And using windows credentials for authentication would be an advantage but not a requirement as long as the client is able to store the credentials.
I have had a (really) quick look at Git, Mercurial and Bazaar.
Git seemed to use ssh or simple WebDAV for repository access, requiring write permission for the users.
Mercurial had a built in http server, but this seemed to be only for pull purposes. Update: Mercurial supports push as well.
Bazaar Seemed to use sftp for repository access, again requiring a write permission for the users.
Are there windows server processes for any DVCS systems and has anyone managed to set one up in a Windows land?
And apologies if this is a duplicate question. I couldn't find one.
Update
Got Mercurial working for push purposes! Detailed list what was required can be found as an answer below.
Mercurial's almost certainly your easiest option on Windows.
If you didn't care about authentication, you actually can trivially allow hg serve to permit push. To do so, you merely need to add the following to the .hg/hgrc file in the repository you wish to serve:
[web]
allow_push = *
push_ssl = false
The first line says that anyone may push to this repository. The second tells Mercurial to allow pushing without SSL, since hg serve does not currently natively support HTTPS. At this point, users can push to your repository without having an account anywhere. If you're simply a small shop, that's probably fine--especially since you can use Mercurial's ability to sign changesets to guarantee a much higher level of verifiability than HTTP Basic will provide, anyway.
For a larger, shop, though, you'd be totally right in wanting at least a simple barrier for committing. To do that, you need to make two changes. First, you'll need to put Mercurial behind a web server with either reverse proxy support or CGI support. Thankfully, recent versions of IIS support both. You can consult the CGI directions in the Mercurial Redbook for Mercurial-specific steps, and Microsoft's guide to setting up CGI applications in IIS 6 for help on the IIS side.
Next, you'll need to set up some basic authentication. IIS provides HTTP Basic out-of-the-box, which, as a bonus, can authenticate directly against your domain, keeping administrative overhead to a minimum.
Finally, you'll want to change the allow_push line to support only specific users by specifying a comma-delimited list of user names. For example:
allow_push = benjamin, ted, the_cow
That's it. Mercurial will now allow push from users who can authenticate via HTTP Basic authentication, and allow pull from everyone else.
After Benjamin pointed out the HTTP serving CGI scripts I decided to try those out and managed to get a repository hosted over HTTP. The Redbook which Benjamin linked was of much help as were two Mercurial wiki articles. One which describes Mercurial publishing in general and another containing step by step instructions for setting up the HgWebDir CGI script.
These instructions weren't completely foolproof though so I had to poke around a bit. Most likely as I'm running 64bit Vista. The instructions below document what I did. Now that I've done it once I'd probably do things in another order so don't consider these step by step instructions.
Mercurial
First I acquired the Mercurial binary from http://mercurial.berkwood.com/ which got installed into d:\dev\Mercurial. I created a repository for testing under d:\dev\testRepo repository using hg init. The d:\dev\Mercurial\library.zip contains Mercurial library files required by the CGI script so they were extracted to d:\dev\Mercurial\library. Something which confused me at first is that when I opened the zip file I received an error message and saw no contents. Just extracting the file to a directory worked though.
For the web script, I downloaded Mercurial source which contained the hgwebdir.cgi which got moved and renamed to d:\dev\Mercurial\webroot\hgwebdir.py. The step by step article contains good instructions for modifying the hgwebdir script for Windows. They also contain instructions for hgweb.config which in my case ended up looking like this:
[paths]
/hg/hgwebdir.py/test = D:\dev\Mercurial\testRepo
Also the repository wanted the following config so I could push there without SSL. Note I am using Basic Authentication to authenticate users currently. I had to create the config in D:\dev\Mercurial\testRepo\.hg\hgrc and add the following lines to it:
[web]
allow_push = *
push_ssl = false
Python
The CGI script is a Python script so it requires Python. It's seems pretty picky on which Python version executes it. One of the articles mentioned that running it requires same version that was used to build the Mercurial. In the end I got it working on Python 2.5 x86 after trying Python 2.6 x64, Python 2.4, Python 2.5 x64.
IIS
Two things I missed and had to install were CGI support and Basic Authentication. Both of these were installed through Control Panel, Programs and Features. Once done with installation I created a virtual directory (Which I later changed to an Application) in IIS pointing to D:\dev\Mercurial\webroot. The virtual directory required an CGI handler for *.py files which could be added from Handler Mappings. The executable was D:\dev\SDKs\Python25_x86\Python.exe %s. Once IIS had permissions to the webroot directory I could navigate to http://localhost/hg/hgwebdir.py/test and see the repository.
So now the read access was working. When I tried pushing to the repository I received weird error messages telling me it wasn't a real repository.
After an hour of debugging I ended up copying the whole D:\dev\Mercurial\library\mercurial tree under webroot so that Python could find D:\dev\Mercurial\webroot\mercurial\hgweb\hgwebdir_mod.pyc. After this Wireshark was reportting Access Denied errors in the stack trace. No idea what the real reason to this was but changing the virtual directory into an Application in IIS and moving it on top of an application pool which ran using Local System account the access denied errors went away.
Also at some point I gave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters registry key more permissions so IIS could access it. Doubt that it requires these after using Local System account.
Once these were done pushing stuff to the repository using hg push http://localhost/hg/hgwebdir.cgi/test was working!
Problems and solutions
Where to find the library files.
They were in the library.dll under Mercurial installation folder. I just had to extract them even if my unzip program refused to view me its contents.
How to get the Python script to run
Download the correct Python version for x86 architecture as the script uses some x86 libraries. The correct Python version depends on the Mercurial version. For 1.2.1 it was Python 2.5 x86.
Alternatively you could try building Mercurial from sources with whatever Python version you want but in my case this failed when building extensions.
How to set CGI up in IIS
First make sure CGI is installed in IIS. This wasn't assumed to be true in the IIS instructions Benjamin posted.
Create a new Module Mapping for *.py in IIS Handler Mappings. The correct Module is CgiModule and the executable is your Python executable + %s
How to allow the CGI script to write to the repository
Make sure the script has everything it requires. I had to move the library\mercurial\hgweb\hgwebdir_mod.pyc to another place.
Make sure the script has permissions to everywhere it wants. I solved this by Creating a new Application Pool for the CGI script that used Local System account, converting the Virtual Directory to an Application in IIS and selecting the new Application Pool.
After reading Mikko's Answer which almost worked for me, I came up with my own notes for installation. My setup was designed to be a "non protected and open" repository that members of my team could use installed on a Windows 2008 Server.
1. Install Python.
The version of Python I used was Python 2.6.2 and I used the Windows x86 MSI Installer.
Install for all Users.
Install to C:\Mercurial\Python
Use Default Feature Options.
2. Install MinGW.
The version of Minimalist GNU for Windows I used was MinGW 5.1.4
Install the MinGW-5.1.4.exe.
Choose the Download and Install Option.
Choose the Current Package Option to Install.
For the Components to Install Select the "Minimal" option.
Install to C:\Mercurial\MinGW
3. Modify your path.
You need to add in locations to your environmental path at this point.
Add 'C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
4. Install Mercurial.
The version of mercurial that I used was the latest release in the stable branch and I did not use the binaries, but used the source code. I wanted to compile mercurial myself so that it would work with whatever version of Python I had installed so I didn't have to worry about any compatability issues which I found to be the biggest challenge with other install methods. The easist way to get the source is by downloading the "zip" file.
Mercurial Stable Release
Extract Zip File to C:\Mercurial\Source.
Build the Source at command prompt.
python setup.py build --force -c mingw32
python setup.py install --force --skip-build
5. Modify your path.
You need to insert into your environmental path another location for the 'hg' command.
Add 'C:\Mercurial\Python26\Scripts;C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
6. Create your Config file.
You need to have a default user name set if your going to do any commits locally on this server.
Create file '"C:\Documents and Settings{username}.hgrc"'
[ui]
editor = Notepad
username = your_name
6. Test your Install.
Open up a new command window and test with 'hg debuginstall' to validate. You should see something like the following.
Checking encoding (cp1252)...
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected
7. Setup Web Directory.
Create Directory 'C:\Mercurial\Web'
Copy the hgwebdir.cgi file from the 'C:\Mercurial\Source' to 'C:\Mercurial\Web'
8. Configure IIS7 for Centralized Repository.
I used the DefaultAppPool which is using .Net 2.0, Pipeline=Integrated, Identity = ApplicationPoolIdentity.
Ensure CGI features are available in IIS7.
Control Panel/Programs/Windows Features/IIS/App Development Features/CGI
Add App into IIS on the Website you wish.
Alias=Mercurial -- Physical Path=C:\Mercurial\Web
On the App select HTTP Modules and add a new Module Mapping.
Request Path=*.cgi, Module=CgiModule, Executable=C:\Mercurial\Python26\python.exe %s, Name=Mercurial.
When Prompted to add entry to ISAPI and CGI restrictions list say yes.
9. Test your Web Setup.
You should now be able to browse http://localhost/Mercurial/hgwebdir.cgi and see and empty repository list.
10. Configure IIS7 for Friendly URL
I did not like having the unfriendly URL and this step allows us to remap the URL to something more friendly. Install the URL Rewrite Moduel 1.1 Extension for IIS.
On the Mercurial IIS Application in IIS Manager featurs View select URL Rewrite Component and install a new Rule.
Choose Add Rules, then the Template 'Rule with rewrite map.' Rule Action=Rewrite, Specify Rewrite Map=Mercurial
Add a mapping Entry. OriginalValue='/Mercurial/Repo', New Value='/Mercurial/hgwebdir.cgi'
11. Create Mercurial Repository
You can now create a test repository.
Create a Directory C:\Mercurial\Repository and ensure IUSR account has the permissions to write to the directory. (If on Domain account is more like IUSR_{ComputerName}.
Create file C:\Mercurial\Web\hgweb.config to list the repositories.
[paths]
/ = C:\Mercurial\Repository\**
Add a directory C:\Mercurial\Repository\Test and initialize the repository with 'hg init'
** If you want now to be able to push without ssl create in the .hg directory of the repository a hgrc file the following lines.
[web]
allow_push = *
push_ssl = false
References:
Mercurial Wiki Windows Install
HG Book
Step by Step
Publishing Mercurial Repositories
For a team taking the first step away from VSS I would have suggested using SubVersion for source control and either TortoiseSVN or VisualSVN for the client.
But if the team has made the decision to switch to a DVCS then I'd suggest Mercurial because of it's better support for HTTP and windows on the client via TortoiseHg.
If you're looking for:
Distributed development support
Run Windows servers seamlessly
And a great GUI
You're exactly describing Plastic SCM
Excuse my necroposting and shameless self-promotion, but I've just released an alpha version of HgLab, which is a Mercurial Server for Windows with full pull-push support and Active Directory integration.
SCM-agnostic (to some degree) Windows-solution with Repository-frontent and management today may be SCM-Manager (Git, Mercurial, SVN repo out of a box with a single requirement of JVM)