I've successfully created my first OmniAuth strategy and packaged it as a gem. I added this to the Gemfile in GitLab and ran bundle install --path vendor/bundle --no-deployment, which installed the gem.
Next I updated the gitlab.yml file by duplicating the section we have for GitHub and completing it with our own values.
As directed by the GitLab reference instructions at https://github.com/gitlabhq/gitlabhq/blob/5-3-stable/doc/install/installation.md
I then added two image files to the vendor/assets/images/authbuttons directory, all lowercase in the format of "strategyname_32.png" and "strategyname_64.png".
Finally I restarted GitLab and on the login page I now see a button for our new provider (which works, yea!) but the images that I uploaded aren't used for the button, instead a basic grey button is being used.
I cannot find anything in any of the logs indicating that it's not able to find the image files and I've tried renaming the files using various cases since this is on a Ubuntu system.
I also executed a rake assets:precompile RAILS_ENV=production but that didn't seem to make a difference.
Am I missing something to get this provider to be represented by our image instead of the basic HTML button on the login page? I don't see any steps that I've missed in the instructions.
It turns out this is "by design" that additional providers load as an HTML button and don't use a graphic placed in the path vendor/assets/images/authbuttons as mentioned in the installation instructions. This is because only providers listed in the default_providers() function within the app/helpers/oauth_helper.rb use images in the vendor/assets/images/authbuttons directory to display on the login page.
So for me to successfully use my custom omniauth provider and have a graphic element for the login link on the GItLab login page I did the following:
Stop GitLab sudo service gitlab stop
placed my two graphics in the vendor/assets/images/authbuttons directory
added my provider as one of the default providers in the default_providers() function of the app/helpers/oauth_helper.rb file
Added a section for my provider in config/gitlab.yml with the client_id and client_secret
Added my omniauth strategy to the Gemfile file
Installed the gem from the GitLab root directory using sudo -u git -H bundle install --without development test postgres --path vendor/bundle --no-deploy
Precompiled the assets from the GitLab root directory using sudo -u git -H rake assets:precompile RAILS_ENV=production
Start GitLab sudo service gitlab start
Related
I'm running Sonatype Nexus 3 inside a docker container, with the following startup command:
docker run -d -p 80:8081 --ulimit nofile=65536:65536 --name nexus -v nexus-data:/nexus-data -e INSTALL4J_ADD_VM_PARAMS="-Xms4g -Xmx4g -XX:MaxDirectMemorySize=6717m -Djava.util.prefs.userRoot=${NEXUS_DATA}/javaprefs" sonatype/nexus3
After updating the docker image version from 3.30.0 to 3.40.1, I keep getting the following warnings regarding user prefs.
2022-07-18 13:14:45,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
2022-07-18 13:15:15,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Could not lock User prefs. Unix error code 2.
As you can see from the startup command, the user prefs directory is inside the docker volume and at directory /nexus-data/javaprefs . I have tried looking for existing locks inside the directory, but found none. I've also tried completely deleting the directory and saw that the warning still came up and the folder itself wasn't being created by Nexus.
I honestly don't even know if this is an important issue or not, since there is little to no documentation about the user preferences folder.
Even a way to turn off the warning log which fires every 30s would be useful.
----UPDATE----
I've tried doing a clean installation of Nexus through Docker, following the simple instructions inside the github sonatype nexus3 docker repository, and still find these warnings.
I even tried on a different OS (Windwos instead of linux, through Docker Desktop) and with and without a volume for /nexus-data.
At this point I believe it to be a bug in a newer Nexus version.
TLDR: Adding -Djava.util.prefs.userRoot=/nexus-data/javaprefs should solve the problem, assuming the nexus data directory is at /nexus-data/.
Just had the same issue after upgrading from 3.38.1 to 3.42.0. After some investigation found that indeed the java.util.prefs.userRoot property got lost somewhere between those versions. The default value in the vanilla Nexus 3.38.1 is /nexus-data/javaprefs.
I have created a new custom cartridge, in which I have packaged into an rpm using tito and installed using yum. This cartridge is being copied from my spec file to the /usr/libexec/openshift/cartridges directory, however, when I log into the origin home site and try to create an application my cartridge does not show up. I went digging in the ruby scripts and I found that there is a script named cartridge_cache.rb seems to be caching the cartridges it finds within the /usr/libexec/openshift/cartridges directory. I have tried to get origin to reload the cache to include my new cartridge by removing all the cache files within the /var/www/openshift/broker/cache directory then restarting the broker, but I have had no success. Is there somewhere I need to hardcode my cart name to some global variable or something ? Basically, Does anyone know how to get your custom cart to show up on the webpage for creating a new application.
UPDATE: So I ran into a slide deck that had one slide on how to install the cartridge. However, I still have had no success, but here is what I have tried since the previous post:
moved my cartridge directory from /usr/libexec/openshift/cartridges to /usr/libexec/openshift/catridges/v2
ran this command
oo-admin-cartridge -a install -s /usr/libexec/openshift/cartridges/v2/myfirstcart
which the output stated it installed the cartridge.
cleared cache with
bundle exec rake tmp:clear
restarted the openshift broker service
Also, just to make sure the cache was cleared out I went into the Rails console and ran Rails.cache.clear. And still no custom cartridge on the openshift webpage.
It works for me after cleaning cache
cd /var/www/openshift/broker
bundle exec rake tmp:clear
and restarting broker service
service openshift-broker restart
http://openshift.github.io/documentation/oo_administration_guide.html#clear-the-broker-application-cache
MCollective service on Node server (if you have separate servers for broker and node) must be restarted. e.g. with
service ruby193-mcollective restart
After that you should clear the caches on broker server e.g with
/usr/sbin/oo-admin-broker-cache --console
Then you should have new cartridges available
I'm having a problem running the oink gem on my app in Heroku. I've included it in my gemfile and gemfile.lock, uploaded those, and it installs. It even creates the oink.log (which I have no way of viewing, unfortunately). When I run
heroku run bundle exec oink --threshold=0 log/* --app my_app
I get
Running bundle exec oink --threshold=0
log/delayed_job.log log/development.log log/oink.log log/production.log log/test.log attached to terminal... up, run.3
/app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:88:in get_file_listing':
Could not find "log/delayed_job.log" (RuntimeError)
from /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:86:ineach'
from /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:86:in get_file_listing'
from /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:59:inprocess'
from /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/oink:4
from /app/.bundle/gems/ruby/1.8/bin/oink:19:in 'load'
from /app/.bundle/gems/ruby/1.8/bin/oink:19
I've tried running each of the individual files, too, and get the same result. This command runs fine on my local machine.
In my production.rb file, I have
config.logger = Hodel3000CompliantLogger.new(config.paths.log.first)
config.middleware.use( Oink::Middleware )
as configuration.
Can you enlighten me on what I'm doing wrong here? My understanding is that the logs are read only, but I don't know if that means they're only accessible through the heroku logs command. If there's a way I can see the oink.log file, too--knowing how to do that is also appreciated, or knowing how to see it in the actual Heroku log using heroku logs.
UPDATE: The configuration for oink shown above allows the commands to be run successfully on my localhost.
Thanks!
-Andrew
I'm trying to get my application, which does not appear in the Dock, to have an option to launch at login. This is tricky, and involves creating a second, helper application which you add as a startup item. This helper app is only responsible for launching the main app and then exiting.
I've followed the instructions here and here and it works like a charm - the problem is, of course, code signing. I have two targets; the helper app target is copied to the Contents/Library/LoginItems subdirectory of the main bundle at compile time. Each bundle has its own bundle identifier and own deployment provisioning profile, but when I validate my archive for the app store, I get the following error:
Invalid provisioning profile. The provisioning profile included in the bundle BUNDLE NAME [BUNDLE NAME.app] is invalid. For more information, visit the Mac OS Developer Portal.
If I remove the helper bundle from my main target, there's no problem. It looks like the presence of another provisioning profile is setting off the error.
How can I include two signed bundles and pass the validation?
I was finally able to resolve this problem by using codesign on a coworker's computer (there must have been something wrong with my Keychain) and deleting the embedded.provisionprofile file from the helper app by adding the following run script:
if [ -f "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/embedded.provisionprofile" ];
then
rm "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/embedded.provisionprofile"
echo "Removed embedded provisioning profile."
else
echo "No profile found"
fi
You should use the same Mac App Store Production Certificate to sign both the helper app and the main application. I haven't tried this in Xcode — we have a helper app that's a bundle resource, but our code signing is a command line script. We didn't have any problems with the app store system.
I'm not sure why you're ending up with a provisioning profile in the built product, and I don't think this is required for app store submission. You can try using codesign manually:
codesign -f -s "3rd Party Mac Developer Application: My Company" \
-i "com.mycompany.loginitem" \
--entitlements path/to/loginitem.entitlements" \
path/to/appname.app/Contents/Library/LoginItems/loginitem.app
codesign -f -s "3rd Party Mac Developer Application: My Company" \
-i "com.mycompany.appname" \
--entitlements path/to/app.entitlements" \
path/to/appname.app
I had the same problem. Instead of removing embedded.provisionprofile from the helper app I've just disabled provisioning (Provision profile: None) leaving code signing identify and entitlements in place. Submitted my app for review without any issues.
I want to open the gem with textmate.
So I am using following commands:
export BUNDLER_EDITOR=mate
bundle open unicorn
Error:
Could not find gem 'unicorn' in the current bundle.
Note:
1)This commands used to work perfectly and it opened the whole gem with its contents, but suddenly some thing went wrong.
2) I am using rvm to manage my gems, & when i do : $gemset list, I do see the list of gems.
3) I also tried to automate the process by putting "export BUNDLER_EDITOR=mate" inside the ~/.profile file inside my user folder.
4) When i do -> echo $EDITOR , I dont get any output
I also faced the similar problem. Although i am not a pro, but you should try to use another rvm gemset, Instructions are listed here http://beginrescueend.com/gemsets/using/