Re: Autoformat source code issue

I thought GIT does this automatically on Windows. On Mon, Apr 20, 2020 at 10:30 AM Lyor Goldstein wrote: > I have just fetched the latest master branch and built it on my Windows > machine and am getting as if all files have been changed - the change has > to do with LF -> CRLF change in all

Re: [mina-sshd] 01/02: [SSHD-660] Add support for serer side openssh host certkeys

Yes, sorry for the noise. I must have used a not clean repo before building or maybe not rebuild from root, not sure. Anyway, I can confirm that it's working for me too. Le lun. 20 avr. 2020 à 15:37, Lyor Goldstein a écrit : > >> I think your forgot to commit the changes to a few files:

Re: [mina-sshd] 01/02: [SSHD-660] Add support for serer side openssh host certkeys

>> I think your forgot to commit the changes to a few files: KeyUtils, KeyPairProvider I don't think so - I have used the cloned repository commits rather that the PR + the code compiles and passes all tests.

Re: [mina-sshd] 01/02: [SSHD-660] Add support for serer side openssh host certkeys

I think your forgot to commit the changes to a few files: KeyUtils, KeyPairProvider Le dim. 19 avr. 2020 à 18:00, a écrit : > This is an automated email from the ASF dual-hosted git repository. > > lgoldstein pushed a commit to branch master > in repository

Re: [SSHD] Autoformat code

>> Unless there's a strong objection, i'll soon commit the changes in I have no strong objection, but I am a bit confused why this is better than checkstyle. Please bear in mind that checkstyle is not only about indentations but also imposes what are currently considered good practices (e.g.,

Re: [jira] [Created] (DIRMINA-1123) Receive buffer size is never set for NIO acceptor

The socket buffers don’t do anything with listening TCP sockets nor do accepted sockets automatically inherit any settings therefore it isn’t necessary. On Wed, Apr 15, 2020 at 5:09 AM Marcin L (Jira) wrote: > Marcin L created DIRMINA-1123: > - > >

Re: Need Help on SSH with External Proxy

>> unfortunately our servers are staying in corporate network which desnt have access to outside sftp server and we wanted to use proxy over to transfer the file. >> Could you please help us with any java sample on sshd connection over proxy for sftp or any documentation to use proxy would be

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Hi Emmanuel, Things are definitely moving smoothly; I can say the migration already has been completed and mina.a.o is served from git now. One thing that may be good to do is add a MOVED_TO_GIT here [1]. MINA has already been disabled from the CMS. Also, the Jenkins job [2] seems to do its

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Hi Roy, are things moving smoothly ? When do you think we would be able to done ? (just wondering, no urgence). Thanks a lot ! - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail:

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Thanks Guillaume! The Jenkins job for building the site has been created [1], and a PR for moving over is created as well [2] Last chance to say goodbye to the CMS :P [1] https://builds.apache.org/job/mina-site/ [2] https://github.com/apache/infrastructure-puppet/pull/1730 On 2020/02/24

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

I've pushed the 4 branches. Thx ! Le lun. 24 févr. 2020 à 16:41, Roy Lenferink a écrit : > Thanks Emmanuel! Requesting repositories is selfservice, so indeed they > will be available pretty > quick :) > > I have everything available in my copy of the mina-site repository here > [1] > > The

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Hey Emanuell, I missed the vote… but I am +1 too… Jeff > On Feb 24, 2020, at 8:41 AM, Roy Lenferink wrote: > > Thanks Emmanuel! Requesting repositories is selfservice, so indeed they will > be available pretty > quick :) > > I have everything available in my copy of the mina-site

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Thanks Emmanuel! Requesting repositories is selfservice, so indeed they will be available pretty quick :) I have everything available in my copy of the mina-site repository here [1] The repository contains the 4 needed branches: - asf-site => contains the generated content which will be

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

On 24/02/2020 09:38, Emmanuel Lécharny wrote: Hi, On 22/02/2020 16:21, Roy Lenferink wrote: Hi, The vote has passed with the following results: +1 Guillaume Nodet (binding) +1 Emmanuel Lécharny (binding) +1 Jeff Maury (binding) +1 Roy Lenferink (non-binding) No -1 votes have been cast.

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

Hi, On 22/02/2020 16:21, Roy Lenferink wrote: Hi, The vote has passed with the following results: +1 Guillaume Nodet (binding) +1 Emmanuel Lécharny (binding) +1 Jeff Maury (binding) +1 Roy Lenferink (non-binding) No -1 votes have been cast. To continue I'll need some help from a PMC member

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

Adding my +1 (non-binding) as well. On 2020/02/19 13:45:51, Roy Lenferink wrote: > Hi MINA community, > > After last weeks proposal [1] I'd like to start a formal vote for moving over > from the current Apache > CMS (and SVN) to use Hugo and git. > > Short recap about Hugo: Hugo is a static

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

+1 Le mer. 19 févr. 2020 16:56, Emmanuel Lécharny a écrit : > +1 too. > > On 19/02/2020 16:03, Guillaume Nodet wrote: > > +1 > > > > Thx for pushing that. The change will be a huge gain. > > > > Le mer. 19 févr. 2020 à 14:45, Roy Lenferink a > > écrit : > > > >> Hi MINA community, > >> > >>

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

+1 too. On 19/02/2020 16:03, Guillaume Nodet wrote: +1 Thx for pushing that. The change will be a huge gain. Le mer. 19 févr. 2020 à 14:45, Roy Lenferink a écrit : Hi MINA community, After last weeks proposal [1] I'd like to start a formal vote for moving over from the current Apache CMS

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

+1 Thx for pushing that. The change will be a huge gain. Le mer. 19 févr. 2020 à 14:45, Roy Lenferink a écrit : > Hi MINA community, > > After last weeks proposal [1] I'd like to start a formal vote for moving > over from the current Apache > CMS (and SVN) to use Hugo and git. > > Short recap

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

Apologies if I missed something! This is about moving the source for the mina.apache.org site, which is currently served from SVN [1], to a new mina-site git repository (to be created after vote passes). This repository will be synced between gitbox.a.o and GitHub. After this, I will create a

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

Just to clarify - is this about moving to Git on GitHub, or is it about moving to Git using a different host for the upstream repository? On Wed, Feb 19, 2020 at 7:52 AM Roy Lenferink wrote: > > Hi MINA community, > > After last weeks proposal [1] I'd like to start a formal vote for moving over

Re: Moving MINA site from SVN to Git

Hi all, Any further thoughts on this? Otherwise I'll start a (lazy) vote for moving over. Roy On 2020/02/13 12:35:33, Roy Lenferink wrote: > Hi folks, > > Following up on this. > > After doing a bit of research I noticed Apache Beam is doing something > similar that could be useful > for

Re: Moving MINA site from SVN to Git

Hi folks, Following up on this. After doing a bit of research I noticed Apache Beam is doing something similar that could be useful for Apache MINA as well.Their generated documentation is hosted on a separate branch, e.g. release-docs [1] which is then propagated into the site [2]. This

Re: Moving MINA site from SVN to Git

Hi Emmanuel, Thanks for your reply! See my inline comments. On 2020/02/10 23:34:29, Emmanuel Lécharny wrote: > Hi Roy, > > On 10/02/2020 16:00, Roy Lenferink wrote: > > Hello MINA developers, > > > > I noticed MINA is still serving its site from SVN with help of the Apache > > CMS. > > Yes.

Re: Moving MINA site from SVN to Git

Hi Roy, On 10/02/2020 16:00, Roy Lenferink wrote: Hello MINA developers, I noticed MINA is still serving its site from SVN with help of the Apache CMS. Yes. It has been this way for around a decade (actually, as soon as the CMS was proposed). before that we were using a buggy Confluence ->

Re: Dear Sir, I need Help, Emergency, MINA SSL configuration not connect remote client at server side.

Open up Wireshark and figure out what is going on. What is the domain name on your SSL cert? Is it your IP address or is it localhost? On Sat, Feb 1, 2020 at 4:10 PM Kutay C. Zorlu wrote: > Hi - ALL, > > I am student, I have a master thesis project, I Integrated Apache mina to > my Project,

Re: [RESULT] [VOTE] Release Apache Mina SSHD 2.4.0

The release is available on the apache distribution sites, but it has a problem syncing to central, see https://issues.apache.org/jira/browse/INFRA-19798 I'll update the web site, but feel free to prepare an announcement email so that we can send it when the sync is done. Le lun. 27 janv. 2020 à

Re: [RESULT] [VOTE] Release Apache Mina SSHD 2.4.0

>> I'm thus closing the vote with 3 +1s and no other votes and will publish the release and update the web site asap. Great - let me know if you want me to publish an announcement or you will do it. Thanks, Lyor

Re: [VOTE] Release Apache Mina SSHD 2.4.0

Did I miss this? +1 from me. Jeff > On Jan 26, 2020, at 4:07 PM, Guillaume Nodet wrote: > > I think we're still missing a binding vote..., we need at least 3. > > Le sam. 18 janv. 2020 à 09:02, Guillaume Nodet a écrit : > >> I've staged a release candidate: >> * Repo: >>

Re: [VOTE] Release Apache Mina SSHD 2.4.0

On 27/01/2020 00:07, Guillaume Nodet wrote: I think we're still missing a binding vote..., we need at least 3. Hi Guillaume, AFAICT, I count 3 +1 binding votes : you, Lyor and me... Le sam. 18 janv. 2020 à 09:02, Guillaume Nodet a écrit : I've staged a release candidate: * Repo:

Re: [VOTE] Release Apache Mina SSHD 2.4.0

I think we're still missing a binding vote..., we need at least 3. Le sam. 18 janv. 2020 à 09:02, Guillaume Nodet a écrit : > I've staged a release candidate: > * Repo: > https://repository.apache.org/content/repositories/orgapachemina-1047 > * Distributions: >

Re: [VOTE] Release Apache Mina SSHD 2.4.0

+1 Le sam. 18 janv. 2020 à 09:02, Guillaume Nodet a écrit : > I've staged a release candidate: > * Repo: > https://repository.apache.org/content/repositories/orgapachemina-1047 > * Distributions: >

Re: [VOTE] Release Apache Mina SSHD 2.4.0

My +1 Packages built from repository and distribution, signature checked. Good to go ! On 18/01/2020 09:02, Guillaume Nodet wrote: I've staged a release candidate: * Repo: https://repository.apache.org/content/repositories/orgapachemina-1047 * Distributions:

Re: [VOTE] Release Apache Mina SSHD 2.4.0

So I've removed the md5 and sha1 files for the distributions: https://repository.apache.org/service/local/repositories/orgapachemina-1047/content/org/apache/sshd/apache-sshd/2.4.0/ Le lun. 20 janv. 2020 à 14:09, Guillaume Nodet a écrit : > I think we're fine, we do provide the .asc PGP armored

Re: [VOTE] Release Apache Mina SSHD 2.4.0

I think we're fine, we do provide the .asc PGP armored signatures. I'll remove the .md5 and .sha1 files from the repository. Le lun. 20 janv. 2020 à 13:47, Emmanuel Lécharny a écrit : > Hi guys, > > > I'm sorry, but new release *MUST* be signed using something stronger > than MD5 or SHA1 : > >

Re: [VOTE] Release Apache Mina SSHD 2.4.0

Hi guys, I'm sorry, but new release *MUST* be signed using something stronger than MD5 or SHA1 : https://www.apache.org/dev/release-distribution.html#sigs-and-sums : "SHOULD NOT supply a MD5 or SHA-1 checksum file (because these are deprecated)" On 18/01/2020 09:02, Guillaume Nodet

Re:[VOTE] Release Apache Mina SSHD 2.4.0

Thanks Guillaume... +1 I've staged a release candidate: * Repo: https://repository.apache.org/content/repositories/orgapachemina-1047 * Distributions: https://repository.apache.org/content/repositories/orgapachemina-1047/org/apache/sshd/apache-sshd/2.4.0/ * Git Tag:

Re: SSHD 2.4.0

>> Some of the tests do consistently fail on my laptop during the release process Strange but not surprising - the MINA and NETTY tests do have inconsistent intermittent failures . Usually if I run `mvn -rf :sshd-mina` (or whatever failed) a few times they succeed. Note that it can happen

Re: SSHD 2.4.0

dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.* *[ERROR]* -> *[Help 1]* *[ERROR]* *[ERROR]* To see the full stack trace of the errors, re-run Maven with the *-e* switch. *[ERROR]* Re-run Maven using the *-X* switch to enable full debug logging. *[ERRO

Re: SSHD 2.4.0

Great - then we can proceed Yes, it seems to fix the issue. Le ven. 17 janv. 2020 à 09:04, Lyor Goldstein a écrit : > I have downgraded the plexus.archiver.version back to 4.1.0 and now I > believe it works (have not committed or pushed to master). Please check it, > and if it works make the

Re: SSHD-2.4.0

Yes, it seems to fix the issue. Le ven. 17 janv. 2020 à 09:04, Lyor Goldstein a écrit : > I have downgraded the plexus.archiver.version back to 4.1.0 and now I > believe it works (have not committed or pushed to master). Please check it, > and if it works make the necessary commit in the master

Re: SSHD-2.4.0

I have downgraded the plexus.archiver.version back to 4.1.0 and now I believe it works (have not committed or pushed to master). Please check it, and if it works make the necessary commit in the master branch.

Re: SSHD-2.4.0 ?

I have looked and there is no upgrade for javadoc plugin. A quick look at the root pom.xml commit history shows (commit 794ebd83f931c15c4343480cc393c5f2cc486416) previous -3.4.0 -4.1.0 upgraded +3.5.0 +4.2.1 I suggest you try the older combination and see if it

Re: SSHD 2.4.0

>> Sorry for the late reply. >> I did start the release process 2 days ago but hit the following problem. >> Any idea ? I will look into it and let you know shortly - I do have some ideas - basically either try to see if there is a more recent version of the javadoc plugin or

Re: Q: Release SSHD 2.4.0 ?

f foreign imports: 1 [ERROR] import: Entry[import from realm ClassRealm[project>org.apache.sshd:sshd:2.4.0, parent: ClassRealm[maven.api, parent: null]]] [ERROR] [ERROR] - [ERROR] [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full st

RE: Reg: Bypassing Proxy with SSHD SFTP Connection

Gentle reminder.. From: Riyas K K Sent: Monday, November 18, 2019 1:05 PM To: dev@mina.apache.org Subject: Reg: Bypassing Proxy with SSHD SFTP Connection Importance: High Hi, Could you please help me out with setting up Proxy connection in SSHD to upload file to SFTP. An early response

Re: [jira] [Comment Edited] (DIRMINA-989) Frequent CancelledKeyException

I’ll look at this tomorrow On Sat, Nov 2, 2019 at 8:37 PM Srikanth Chadalavada (Jira) wrote: > > [ > https://issues.apache.org/jira/browse/DIRMINA-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965529#comment-16965529 > ] > > Srikanth Chadalavada edited comment

Re: Any Risk to replace the mina sshd dependencied libarary mina-core to verion 2.1.x?

Hi Bruce, the difference between MINA 2.0 and 2.1 is explained on this page : http://mina.apache.org/mina-project/2.1-vs-2.0.html I don't think that impacts SSHd, as sshd-mina module does not check if the session is secured, it is supposed to be secured anyway ! FTR, the mechanism is

Re: Using MINA sshd 2.2.0

Hi All, I have a diferent problem now I want to use the scpclient tp upload and download files Is there a way to upload and download as a different user e.g connect as user A and upload as user B using different passwords Please let me know Thanks Prajwal On 10/16/2019 9:12 PM, Prajwal

Re: Using MINA sshd 2.2.0

Hi Prajwal, Did you see and try something like this? https://mina.apache.org/sshd-project/tips.html --- *Thanks & Regards*, Vijay Shanker |*Software Architect* On Wed, Oct 16, 2019 at 9:15 PM Prajwal M wrote: > Hi All, > > I am currently trying to migrate from JSCH to MINA sshd api's > >

Re: PKCS11 for SSHD

We do not have any current PKCS11 support in MINA SSHD. We do support SSH agents in general, so one could add the necessary support - Java even seems to have some PKCS11 support in it ( https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html) but I have never looked into it.

Re: Reg: Change the buffer size

Hi Thomas, Thanks for the clarification. Then is there a way to restrict the growth of the buffer size? Say not to exceed 65k or so? On Fri, Sep 6, 2019, 6:04 PM Thomas Charron wrote: > Umm, it resizes itself, 1024 is just the initial size. > >Thomas > > > On Fri, Sep 6, 2019, 7:49 PM

Re: Reg: Change the buffer size

Umm, it resizes itself, 1024 is just the initial size. Thomas On Fri, Sep 6, 2019, 7:49 PM Gokkulasudan Rathnakumar < gokkulasudan...@gmail.com> wrote: > Hi All, > Is there a way to change the buffer size in SftpSubsystem under apache sshd > 2.1.0? > > Note: I see it as *protected final

Re: Welcome Réda Housni Alaoui

Hello everyone, Thank you Emmanuel ! I hope I will be up to the task Réda Housni Alaoui > Le 17 août 2019 à 09:26, Emmanuel Lécharny a écrit : > > Hi ! > > > I'm glad to announce that we have a new MINA committer : Réda Housni Alaoui, > who is going to revive the Vysper project ! > > >

Re: [jira] [Commented] (DIRMINA-1118) NPE in SslHandler.checkStatus

Only people with special permissions can edit comments. Don’t worry about it. Are you saying that this issue should be closed because it’s not an issue? On Mon, Aug 12, 2019 at 8:12 AM Christoph John (JIRA) wrote: > > [ >

[jira] [Comment Edited] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

protecting it > SftpSubsystem.destroy() will terminate external FixedThreadPool > ExecutorService - preventing re-connects > > > Key: SSHD-931 >

[jira] [Commented] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

the {{shutdown}} does not invoke the wrapped executor shutdown method - thus protecting it > SftpSubsystem.destroy() will terminate external FixedThreadPool > ExecutorService - preventing re-co

[jira] [Commented] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

ate external FixedThreadPool > ExecutorService - preventing re-connects > > > Key: SSHD-931 > URL: https://issues.apache.org/ji

[jira] [Resolved] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

ies(Collections.singletonList(factory)); {code} > SftpSubsystem.destroy() will terminate external FixedThreadPool > ExecutorService - preventing re-connects > > >

[jira] [Work started] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

ool > ExecutorService - preventing re-connects > > > Key: SSHD-931 > URL: https://issues.apache.org/jira/browse/SSHD-931 > Project: MINA SSHD >

[jira] [Commented] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

ervice - preventing re-connects > > > Key: SSHD-931 > URL: https://issues.apache.org/jira/browse/SSHD-931 > Project: MINA SSHD > Issu

Re: Synchronizing the Apache Mina client connection between threads

I am not sure I understand exactly what you mean - however, it seems that you are on the right track. Assuming indeed that SFTPMinaClientConnector is a prototype bean all you need to do is initialize a session + SFTP on connect and tear them down on close. From what you describe though, it seems

[jira] [Assigned] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

ool > ExecutorService - preventing re-connects > > > Key: SSHD-931 > URL: https://issues.apache.org/jira/browse/SSHD-931 >

Re: Vysper project status

I've asked infra to delete it since it's read-only, I can't even merge any PR... https://issues.apache.org/jira/browse/INFRA-18795 Le jeu. 25 juil. 2019 à 08:42, Réda Housni Alaoui a écrit : > I created https://github.com/apache/vysper/pull/3 to inform of the old > repository deprecation. > I

Re: Vysper project status

I created https://github.com/apache/vysper/pull/3 to inform of the old repository deprecation. I think it should be useful since it is currently the only one found via a Google search. Le jeu. 25 juil. 2019 à 08:33, Réda Housni Alaoui a écrit : > Done =>

Re: Vysper project status

Done => https://github.com/apache/mina-vysper/pull/1 Le jeu. 25 juil. 2019 à 08:29, Réda Housni Alaoui a écrit : > Yeah of course. > Doing it right now > > Le jeu. 25 juil. 2019 à 08:25, Guillaume Nodet a > écrit : > >> I think the correct repository is >>

Re: Vysper project status

Yeah of course. Doing it right now Le jeu. 25 juil. 2019 à 08:25, Guillaume Nodet a écrit : > I think the correct repository is >https://github.com/apache/mina-vysper > Could you please recreate your PR on that one ? > > Le dim. 21 juil. 2019 à 13:47, Réda Housni Alaoui a > écrit : > > > I

Re: Vysper project status

I think the correct repository is https://github.com/apache/mina-vysper Could you please recreate your PR on that one ? Le dim. 21 juil. 2019 à 13:47, Réda Housni Alaoui a écrit : > I created the pull request: > https://github.com/apache/vysper/pull/2 > > Le dim. 21 juil. 2019 à 13:37, Réda

Re: Vysper project status

Le dim. 21 juil. 2019 à 13:37, Réda Housni Alaoui a écrit : > Hi everyone, > > I recently discovered Vysper. I think this is exactly what I need as I want > to use it to expose an existing chat application through XMPP. > I need to add non jetty webapp support to Vysper. > The project does not

Re: Vysper project status

I created the pull request: https://github.com/apache/vysper/pull/2 Le dim. 21 juil. 2019 à 13:37, Réda Housni Alaoui a écrit : > Hi everyone, > > I recently discovered Vysper. I think this is exactly what I need as I > want to use it to expose an existing chat application through XMPP. > I

Re: Fwd: [VOTE] Release Apache Mina SSHD 2.3.0

Missed this one ! Thanks for having forwarded it ! On 15/07/2019 13:45, Guillaume Nodet wrote: -- Forwarded message - De : Jeff Genender Date: mer. 10 juil. 2019 à 16:51 Subject: Re: [VOTE] Release Apache Mina SSHD 2.3.0 To: Guillaume Nodet +1 Jeff On Jul 9, 2019, at 3:22

Re: [RESULT] [VOTE] Release Apache Mina SSHD 2.3.0

Hi Guillaume, sorry to bother you with that, but I count only 2 +1 binding votes :/ I tried the build this morning, but I still have the same 8 errors when. doing so: [INFO] Running org.apache.sshd.common.forward.PortForwardingTest [ERROR] Tests run: 10, Failures: 0, Errors: 8, Skipped: 0,

Re: [VOTE] Release Apache Mina SSHD 2.3.0

+1 Le mar. 9 juil. 2019 à 11:22, Guillaume Nodet a écrit : > I've staged a release candidate: > * Repo: > https://repository.apache.org/content/repositories/orgapachemina-1046 > * Distributions: >

[jira] [Created] (SSHD-931) SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects

Alla Gofman created SSHD-931: Summary: SftpSubsystem.destroy() will terminate external FixedThreadPool ExecutorService - preventing re-connects Key: SSHD-931 URL: https://issues.apache.org/jira/browse/SSHD-931

Re: [VOTE] Release Apache Mina SSHD 2.3.0

+1

Re: Q: release SSHD 2.3.0 ?

The change list is completed - CHANGES.md shows the latest changes as of last release - 2.2.0 in this case - i.e. all changes from 2.2.0 towards 2.3.0. The 2.2.0 file shows the changes from 2.1.0 to 2.2.0. Once you release 2.3.0, I will create a separate file for the 2.2.0 to 2.3.0 changes

Re: Q: release SSHD 2.3.0 ?

I think the change list has not been updated yet. If I read SSHD-872 correctly, we're now using one file per version, which is fine, but I don't see any file for 2.3.0, nor any file pointing to the existing one for 2.2.0. Also, I see that ~/CHANGES.md still exists and contains the 2.2.0 changes ?

Re: Q: release SSHD 2.3.0 ?

>> I'll put that on my todo list ;-) I should be able to find some time before the end of the week. Great, thanks...

Re: Q: release SSHD 2.3.0 ?

I'll put that on my todo list ;-) I should be able to find some time before the end of the week. Le dim. 30 juin 2019 à 18:49, Lyor Goldstein a écrit : > Hi all, > > I believe we have reached a respectable number of bug fixes, features and > improvements to warrant a new release of SSHD.

Re: Sshclient pool

>> Do you have an example for such implementation ? What do you mean ? The code is simple: // Do this ONCE in 'main' SshClient client = setup..and..initialize client.start(); // wherever in the code and as many times a necessary - including concurrently try (ClientSession session =

Re: sshclient pool

>> When you are saying multiple sessions, you mean, I can have one instance with > 1 different sessions to different linux instances with different credentials ? A single SshClient instance can create virtually infinite number of sessions each with a different server (including different ports),

Re: sshclient pool

>> Wanted to advice with you. I have couple of linux instances and I want to hold or keep in memory couple of sshclient Not sure I understand what you mean - basically, unless extremely special requirements/circumstances one needs only one SshClient instance per application. One instance can be

RE: channel request

Goldstein Sent: Sunday, June 16, 2019 7:00 PM To: dev@mina.apache.org Subject: RE: channel request >> How do I set it? Is it better solution then the idletimeout ? See https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic Also:

RE: channel request

l" channel You are right. What shall I do? -Original Message- From: Lyor Goldstein Sent: Sunday, June 16, 2019 6:57 PM To: dev@mina.apache.org Subject: RE: channel request >> I took this code https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/uutils/src/ma

RE: channel request

>> How do I set it? Is it better solution then the idletimeout ? See https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic Also: https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#running-a-command-or-opening-a-shell

RE: channel request

>> I took this code https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/uutils/src/main/java/org/ovirt/engine/core/uutils/ssh/SSHClient.java that is using the sshd The code you mention runs a single (!) command and then exits. I believe your original question was about

RE: channel question

>> By the way, in addition to the previous question. Can I increase the session idle timeout ? Currently 10m, let's say I want it to be 30m ? Easily: see FactoryManager#IDLE_TIMEOUT configuration parameter.Can be done globally - by setting it on the SSH client/server or even per specific

RE: User session has timed out idling after 600000 ms

Thanks Emmanuel for the quick response. Will try that. Regards, Dor -Original Message- From: Emmanuel Lécharny Sent: Sunday, June 16, 2019 5:37 PM To: dev@mina.apache.org Subject: Re: User session has timed out idling after 60 ms On 16/06/2019 16:18, Dor Ben Dov wrote: >

Re: User session has timed out idling after 600000 ms

On 16/06/2019 16:18, Dor Ben Dov wrote: Hi everyone, Is it possible to increase this timeout ? There is no session timeout in MINA: a socket remains opened as long as it's not closed, either by your application, the client, or the OS because it's idling for too long. Now, your OS will

RE: channel question

>> How or can I hold the channel open ? Channels are auto-closeable - i.e., try-with-resource can be used. In other words, it won't close on your end unless you close it. However: >> It seems that once I create and open and actually use the channel, it is being closed without my knowledge. You

Re: channel question

>> Suppose my scripts needs the profile to run at the beginning. I am not sure what "profile" you mean - in the context of SSH there is no such concept. If you mean the ".profile" file (or something similar) that "runs" automatically when you login, then it depends on the definitions of your

Re: [VOTE] Release Apache Miba 2.1.3

+1 Jeff > On May 29, 2019, at 7:19 AM, Emmanuel Lécharny wrote: > > Hi ! > > I'm calling for a vote of Apache MINA 2.1.3 release. > > This fixes a few issues that were found since the last release, mainly a 100% > CPU peak caused by some changes in the way we process the messageSent() >

Re: [VOTE] Release Apache Miba 2.1.3

+1 On Wed, May 29, 2019 at 9:19 AM Emmanuel Lécharny wrote: > Hi ! > > I'm calling for a vote of Apache MINA 2.1.3 release. > > This fixes a few issues that were found since the last release, mainly a > 100% CPU peak caused by some changes in the way we process the > messageSent() event. The 4

Re: New MINA 2.1.X release soon

On 28/05/2019 04:32, Jonathan Valliere wrote: I would like to see DIRMINA-1110 reverted. IMHO, I do not think it fixes any known problems and potentially introduces new deadlock opportunities. Np. I'll do that.

Re: New MINA 2.1.X release soon

I would like to see DIRMINA-1110 reverted. IMHO, I do not think it fixes any known problems and potentially introduces new deadlock opportunities. On Mon, May 27, 2019 at 10:24 PM Emmanuel Lécharny wrote: > Hi ! > > > I think it's time to cut a new release for MINA 2.1.X branch. We have > some

Re: FTPSERVER GIT NOT UPDATING

On 20/05/2019 18:17, Jonathan Valliere wrote: Oh, two mirrors. How do we remove the bad one? I guess we should ask infra...

Re: FTPSERVER GIT NOT UPDATING

Oh, two mirrors. How do we remove the bad one? On Mon, May 20, 2019 at 12:16 PM Emmanuel Lécharny wrote: > > On 20/05/2019 18:02, Jonathan Valliere wrote: > > The GitHub Mirror of FTPSERVER is not automatically updating from Gitbox. > > How do we fix this? > > > I think it does, but there are

Re: FTPSERVER GIT NOT UPDATING

On 20/05/2019 18:02, Jonathan Valliere wrote: The GitHub Mirror of FTPSERVER is not automatically updating from Gitbox. How do we fix this? I think it does, but there are 2 mirrors, one being ftpserver and has stalled, and the other one being mina-ftpserver and seems to be up-to-date with

Re: FTPSERVER mvn error

On 10/05/2019 17:52, Jonathan Valliere wrote: Maven commands work but Maven-Eclipse integration seems to have a problem with the plugins. Ok, same error for me. Just select QuickFix and 'Mark goal check as ignored' for each project in eclipse. That will build, and you won't see any error.

Re: FTPSERVER mvn error

Maven commands work but Maven-Eclipse integration seems to have a problem with the plugins. On Fri, May 10, 2019 at 11:32 AM Emmanuel Lécharny wrote: > Hi Janathan, > > On 10/05/2019 16:30, Jonathan Valliere wrote: > > Emmanuel, > > > > I know you're busy but I would like to figure out why mvn

<    6   7   8   9   10   11   12   13   14   15   >