Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 24 21:25
    jaredledvina synchronize #259
  • Jan 24 21:24
    jaredledvina commented #259
  • Jan 24 21:23
    jaredledvina synchronize #259
  • Jan 24 19:51
    rndmh3ro commented #259
  • Jan 24 19:50
    rndmh3ro commented #258
  • Jan 24 19:06
    rndmh3ro closed #262
  • Jan 24 19:06
    rndmh3ro labeled #263
  • Jan 24 19:06

    rndmh3ro on master

    Remove comment from sshd config… Merge pull request #263 from ab… (compare)

  • Jan 24 19:06
    rndmh3ro closed #263
  • Jan 24 19:06
    rndmh3ro commented #263
  • Jan 24 14:51
    jaredledvina opened #259
  • Jan 24 14:21
    jaredledvina commented #253
  • Jan 22 19:51
    abtreece synchronize #263
  • Jan 22 19:50
    abtreece opened #263
  • Jan 22 19:43
    abtreece opened #262
  • Jan 21 20:40
    artem-sidorenko commented #227
  • Jan 21 20:40

    artem-sidorenko on master

    Fix a typo Signed-off-by: Greg… Merge pull request #227 from gr… (compare)

  • Jan 21 20:40
    artem-sidorenko closed #227
  • Jan 21 07:56
    dennisse commented #260
  • Jan 20 19:45
    rndmh3ro commented #258
Marc Chamberland
@bobchaos
cool, I'ma try this again tomorrow then (work day is coming to an end 'round here!) with the above methodology. I'll leave my broken PR up for now if you want to take a look at the logic, it will be identical in whatever I produce tomorrow
Artem Sidorenko
@artem-sidorenko
then just commit your changes on top, btw its a good idea to use git add -p sometimes and verify the staged area with git diff --stagedprior to the commit
feel free to force push over your created PR or even create a new one if it feels easier for you
https://help.github.com/articles/checking-out-pull-requests-locally/ here is some github docs on getting PR code
Marc Chamberland
@bobchaos
force push over existing sounds cleaner, I'd like to avoid mangling your git history just to squeeze in my changes o.O
Artem Sidorenko
@artem-sidorenko
its up to you, but please do not touch foreign commits without to agree such things with author, in this particular case it should not be a problem because they are more or less trivial, but it's not a good style
Marc Chamberland
@bobchaos
if I'm being perfectly honest, I had no clue what I was doing and just following github's instructions on that one XD I'm going to be doing some reading tonight
Artem Sidorenko
@artem-sidorenko
:-) its completely okay, we are here to help, just feel free to ask
Marc Chamberland
@bobchaos
the git job is a mess ut at least I think you'll like the actual implementation, it handles all possible values as strings OR TrueClass/FalseClass and has the decency to abort the run if you're passing bad values
anyhow, I'm headed home but I'll pick this up tomorrow morning
thx for your help!
Artem Sidorenko
@artem-sidorenko
sounds good!
Artem Sidorenko
@artem-sidorenko
@bobchaos regarding cookstyle and rubocop, you are completely right. We still use the older rubocop version, cookstyle 3 relies on the rubocop 0.55.0 and we have 0.49.1. I created dev-sec/chef-ssh-hardening#210 to address that issue
if you want to do the validation locally, please do it via bundle install ; bundle exec rubocop or similar ways
Marc Chamberland
@bobchaos
Morning @artem-sidorenko I've reopened a PR and leaving it as is for now but it has some issues, just let me know what needs to be done and I'll fix it. I'ma keep an eye on this channel throughout the day
Artem Sidorenko
@artem-sidorenko

@bobchaos good evening :) Can you please add sign-off to your commit?

git commit --amend --signoff
git push --force

in your local clone and branch

and can you please rebase the entire PR on the latest master to resolve the conflict? https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request#perform-a-rebase
Marc Chamberland
@bobchaos
should I squash or plain old rebase?
Artem Sidorenko
@artem-sidorenko
please do not squash, just rebase on the latest master
and resolve the conflict during the rebase
conflct resolution works similar to the conflicts during a merge:
  • you fix the lines in the file, then
  • git add [conflicting file]
  • git rebase --continue
Marc Chamberland
@bobchaos
in answer to your github comment, I can write inspec but not ChefSpec, but I don't mind taking a crack at it. Do we want tests for all possible values?
README fix, rubocop fixes, merge conflict resoltion and rebase all pushed
Artem Sidorenko
@artem-sidorenko
@bobchaos thanks, it looks good. Basic logic check would be enough I think: true/false/ethernet/incorect value
Marc Chamberland
@bobchaos
just pushed some chefspecs, they all come out green but those are my very first chefspec tests, I'd recommend a second look o.O
Artem Sidorenko
@artem-sidorenko
@bobchaos you go into the right direction, but you need another iteration for chefspec tests. Please see my comments in the PR ;-)
Marc Chamberland
@bobchaos
i fixed em according to your comments, will push in a min, but this little adventure reminds me of why i never did chefspecs in the first place: they provide very little benefit over inspec, basic kitchen testing provides the same coverage :/
pushed!
Artem Sidorenko
@artem-sidorenko
@bobchaos thats right, I use chefspec only to test the logic, nothing more. If you would like to test the logic with inspec/test-kitchen, you will have to create another suite -> what if you have several parameters which depend on the logic? To create a new suite for each of them is a bit an overkill, and here is chefspec a pretty good option
Jason Carter
@JasonCarter80
Looking at dev-sec ansible roles, I see Amazon Linux, what about AmazonLinux 2, is it covered?
Marc Chamberland
@bobchaos
@artem-sidorenko should be ready for merge now, thanks a bunch for your help on the git and Chefspec stuff
are there plans for a release soon?
Artem Sidorenko
@artem-sidorenko
@bobchaos I'll have a look tomorrow, if Travis will be green - I'll merge and issue a minor release. Thanks for picking up of this topic and bringing it to a very good and nice end!
Marc Chamberland
@bobchaos
morning! (well, evening!), I'ma do a wee bit of googling and submit the final requested fix in the next hour
Marc Chamberland
@bobchaos
looks like its going to be a busy day for me but I squeezed in the requested change, that said it looks both syntax work (altho my search didn't specify if one syntax may not be more recent or something :/ ). It should now conform to your standards
Artem Sidorenko
@artem-sidorenko
@bobchaos thanks! But its not about style, its about logic:) If you provide a wrong value - you expect to get the exception, so should not it be .to raise_exception?
Marc Chamberland
@bobchaos
o i get it, sorry o.O I should have started my day with more coffee XD
i'ma revert that commit and force push a new one
here's my worry: it was still returning green, so presumably i got something much worse going on no?
Marc Chamberland
@bobchaos
so with .to i get with an invalid string abort the Chef run (FAILED - 1), am I misunderstanding ChefSpec's output, or is my test still not functional? o.O
(that line is red in the output if the coloring means anything)
@artem-sidorenko ^ (when you have a minute, no hurry, just didn't dare to poke you before cuz Germany is far and all humans deserve good sleep ;) )
Artem Sidorenko
@artem-sidorenko
@bobchaos its some weird thing, looks somehow related to the lazy execution with template resouce in the server recipe. Because of lazy execution the exception is somehow catched but ignored within rspec/chefspec. I moved this test to the unit testing of library, this should be enouth. I force-pushed the PR with my fix on top, once travis is green I'll merge it. Thats for good collaboration!
Marc Chamberland
@bobchaos
works for me, I'll keep an eye on the supermarket. Thanks again for all your help, hopefully my next contribution will be more straightforward now that I'm familiar with your process
Artem Sidorenko
@artem-sidorenko
Marc Chamberland
@bobchaos
hurray :D
Artem Sidorenko
@artem-sidorenko
@rndmh3ro I guess the question of @JasonCarter80 is for you :-)
Sebastian Gumprich
@rndmh3ro
@JasonCarter80 Sorry for not noticing your question! We actually use amazonlinux 2!
Artem Sidorenko
@artem-sidorenko
Hi all, as gitter is rarelly used and even not really accepted by all maintainers, we decided to deprecate this communication channel in favour of mailing lists. See this blog post for more details: https://dev-sec.io/blog/2019-02-13-communication-ways/